What happens when a database password, a feature flag, and a plain timeout value all live in the same config file, and one of them needs to change at 2 a.m. without a redeploy? That single question explains why AWS offers three separate configuration services instead of one. Teams that treat them as interchangeable usually end up paying more than they need to, or worse, rotating credentials by hand in a runbook nobody has read since 2023.
The architecture decision in 2027 still comes down to three practical questions: does the value need rotation, how big and how frequently read is it, and do you need staged rollout with rollback? Everything else is detail. Here is how to think it through without drowning in feature matrices.
Three Services, Three Different Jobs
Parameter Store is part of AWS Systems Manager. It stores configuration data and secrets as key-value parameters, and it supports a SecureString type that encrypts values with AWS KMS. That encryption support is the main reason teams reach for it when they want to keep secrets out of source code without adopting a second service.
Secrets Manager is purpose-built for secrets and, critically, for rotation. It includes built-in rotation for Amazon RDS, Amazon Redshift, and Amazon DocumentDB, plus Lambda-based custom rotation for anything else.
AppConfig handles application configuration and feature flags with controlled deployment: validators, gradual rollout, and automatic rollback tied to CloudWatch alarms. It is less a secret store and more a release mechanism for configuration.
A useful mental model: Parameter Store is a filing cabinet, Secrets Manager is a filing cabinet with a shredder on a timer, and AppConfig is a filing cabinet that hands out copies slowly and takes them back if something breaks. (Apple scotus 27 percent app store fee 2026)
The Rotation Question Comes First
If a value grants access to something, ask whether it should change on a schedule. If the answer is yes, Secrets Manager is usually the right home, and arguing about cost before settling this point wastes everyone’s time.
The common mistake is assuming Parameter Store cannot rotate at all. That is imprecise. Parameter Store has no built-in rotation, but rotation can be implemented externally, for example with a Lambda function that generates a new credential and writes it back as a SecureString. Teams do this to save money. They then discover they have built and now own a rotation pipeline, including the failure handling, the alerting, and the on-call rotation for the pipeline itself. That is a real engineering cost, and it rarely shows up in the comparison spreadsheet.
The reverse mistake is putting everything into Secrets Manager, including values that never change, like a region name or a pagination limit. You pay per secret per month plus API calls, and you gain nothing. A non-rotating value in Secrets Manager is a filing cabinet with an idle shredder.
Size, Volume, and the Tier Trap
Parameter Store splits into two tiers. Standard parameters go up to 4 KB with no per-parameter charge. Advanced parameters go up to 8 KB and carry a per-parameter monthly charge plus additional API charges.
The trap is quiet. A team stores a growing JSON blob as a parameter, crosses 4 KB, and silently moves to Advanced. Then they add more parameters, then more environments, and the bill creeps up in a way nobody attributes to configuration. If you store structured documents, split them or reconsider whether AppConfig’s hosted configuration is a better fit.
Volume matters too. Parameter Store Standard has no per-parameter charge, which is why it is the default choice for high-fan-out reads across many services. Secrets Manager’s per-secret and per-call pricing rewards keeping the secret count small and the caching good.
| Decision factor | Parameter Store | Secrets Manager | AppConfig |
|---|---|---|---|
| Primary purpose | General config and secrets | Secrets with rotation | Config deployment and flags |
| Built-in rotation | No | Yes | No |
| Encryption | SecureString via KMS | Native | Via KMS |
| Staged rollout | No | No | Yes |
| Automatic rollback | No | No | Yes, via CloudWatch alarms |
| Feature flags | Not a first-class type | Not a first-class type | First-class type |
| Typical cost shape | Free at Standard tier | Per secret plus API calls | Per request and per config |
Read that table as a starting filter, not a verdict. Most real systems use at least two of the three.
Where AppConfig Actually Earns Its Place
AppConfig separates configuration from code deployment. That sounds like marketing until you have shipped a bad config value and had to roll back a full application release to fix it.
AppConfig supports validators such as JSON Schema and Lambda functions, so malformed configuration is rejected before it reaches production. It supports gradual rollout strategies including linear, exponential, and canary, so a bad value hits a small slice of traffic first. And it supports automatic rollback when a CloudWatch alarm fires. Feature flags are a first-class configuration type alongside freeform and hosted configuration, which means you can turn a feature on for five percent of users without touching a deploy pipeline.
The practical tip: use AppConfig’s validators aggressively. A JSON Schema that rejects a missing field has saved more incidents than any amount of careful code review, because it catches the mistake at the moment a human is editing a value under time pressure.
The common mistake here is treating AppConfig as a secret store. It is not the place for a database password. Keep secrets in Secrets Manager, keep behavioral configuration in AppConfig, and let each service do its job.
A Workable Split for 2027
Most architectures land on a hybrid, and that is fine. A pattern that holds up well:
- Put credentials that must rotate, such as database passwords and third-party API keys, in Secrets Manager with native or Lambda-based rotation enabled.
- Put static, non-sensitive configuration and low-risk secrets in Parameter Store, using SecureString for anything sensitive and Standard tier wherever the size allows.
- Put behavioral configuration and feature flags in AppConfig, with a JSON Schema validator and a canary rollout strategy attached.
- Cache reads in the application. Configuration services are not databases, and hammering them on every request is a self-inflicted latency problem.
- Tag everything by environment and owning team, because the first question in any incident is who changed what.
If you are also running containerized workloads, the same logic applies to how those workloads fetch configuration at startup. The way control plane and worker node responsibilities split in a cluster shapes where config injection belongs, which is worth reviewing alongside your service choice.
Permissions and Blast Radius
Configuration decisions fail for organizational reasons more often than technical ones. A parameter that every service can read is a parameter that every compromised service can exfiltrate.
Scope IAM policies tightly. A payments service should not be able to read the marketing service’s secrets just because both run in the same account. Use separate KMS keys per sensitivity tier so that a key policy mistake does not expose everything at once. And audit who can write and who can read. Write access to a production feature flag is effectively deploy access, and it should be treated that way in your change management process. (NIST Key Management Guidelines)
This is also where the choice between services has a security dimension beyond encryption. Secrets Manager’s rotation reduces the window of exposure automatically. Parameter Store’s SecureString protects data at rest but does nothing about a credential that has been valid for three years. The service you pick sets the default behavior, and defaults win in practice because nobody revisits them.
What Changes in 2027 and What Does Not
The core decision logic is stable. Rotation needs, size and volume, and rollout control have driven this choice for years and will keep doing so. What changes is everything around it: new tiers, pricing adjustments, deprecations, and new integration features.
Anyone publishing 2027-specific claims about AWS configuration services should verify them against the AWS what’s new feed before trusting them, because roadmap items move. Treat any article, including this one, as a framework for asking the right questions rather than a source of current limits. Check the live documentation for tier sizes, per-secret pricing, and rotation support before you commit an architecture.
The other thing that does not change: teams underestimate operational cost. A service you run yourself, like a custom rotation Lambda, is a service you maintain forever. A managed feature you pay for is a line item you can delete. Both are legitimate choices, but only one of them shows up on a calendar reminder at 3 a.m.
Conclusion
The Parameter Store versus Secrets Manager versus AppConfig decision is not a popularity contest. It is a set of three questions asked in order. Does the value need rotation? Then Secrets Manager, unless you genuinely want to own a rotation pipeline. Is it static, small, and read often? Then Parameter Store Standard, with SecureString for anything sensitive. Does it change behavior at runtime and need a safe release? Then AppConfig, with validators and a canary strategy.
Most mature systems use all three, and the teams that get this right are the ones that resist the urge to consolidate everything into one service for the sake of simplicity. Configuration is not one problem. It is three problems wearing the same jacket.
FAQ
What is the main difference between Parameter Store and Secrets Manager?
Parameter Store stores configuration and secrets as key-value parameters, with SecureString providing KMS encryption. Secrets Manager is built specifically for secrets and adds native rotation for RDS, Redshift, and DocumentDB, plus Lambda-based custom rotation. The rotation capability, and its per-secret cost, is the core trade-off.
Can Parameter Store rotate secrets on its own?
No. Parameter Store has no built-in rotation. Rotation is possible, but you build it yourself, typically with a Lambda function that writes a new value back to the parameter. That works, but you then own the pipeline, its failure handling, and its alerting.
When should I use AppConfig instead of Parameter Store?
Use AppConfig when configuration needs a controlled release: validators to reject bad values, gradual rollout to limit blast radius, and automatic rollback when alarms fire. If you just need a value read at startup and changed rarely, Parameter Store is simpler and cheaper.
Is AppConfig a good place to store secrets?
No. AppConfig is designed for application configuration and feature flags, not credentials. Keep secrets in Secrets Manager or Parameter Store SecureString, and keep behavioral configuration in AppConfig. Mixing the two creates permission and audit problems. (AWS Systems Manager Parameter Store user guide)
Why did my Parameter Store bill suddenly increase?
The most common cause is crossing from Standard to Advanced tier. Standard parameters go up to 4 KB with no per-parameter charge; Advanced parameters go up to 8 KB and add a monthly per-parameter charge plus extra API charges. Growing JSON blobs are the usual culprit, so check parameter sizes first.
How many of these services should a typical architecture use?
Often two or three. A common split is Secrets Manager for rotating credentials, Parameter Store for static config and low-risk secrets, and AppConfig for feature flags and staged configuration releases. The right number is whatever keeps each value in the service whose default behavior matches how that value should be managed.
The final check is cultural, not technical. Write down which service owns which class of value, publish that rule where engineers will see it during an incident, and review it when the first bill or the first bad rollout surprises you. That small piece of documentation prevents more drift than any migration.
