Skip to content

SYSTEM Cited by 1 source

AWS Systems Manager Parameter Store

What it is

AWS Systems Manager Parameter Store is the configuration-store subsystem of AWS Systems Manager. It's a managed hierarchical key-value store for configuration values — API endpoints, connection strings, feature flags, thresholds — with built-in versioning, IAM-based access control, and a SecureString type for values encrypted at rest via KMS.

Distinct from Secrets Manager: both can hold secrets, but Parameter Store is positioned for general configuration (lower cost, no built-in rotation), while Secrets Manager ships rotation + cross-region replication as first-class features.

Data model

  • Parameter — a single (name, value, type, version) tuple. Name is a slash-delimited hierarchical path (/app/env/svc/key). Types: String, StringList, SecureString.
  • Hierarchical namespace — slashes in the name form a tree. The GetParametersByPath API retrieves every parameter under a path prefix in one call, recursively if requested. This is the core scaling primitive: one API call can retrieve dozens of related parameters at service initialization instead of one per parameter.
  • Versioning — every write creates a new version; old versions retained; /name:version pins a specific version in reads.
  • Change notifications — Parameter changes emit EventBridge events, which is what makes push-based cache invalidation feasible (see patterns/event-driven-config-refresh).

Canonical appearances

  • Hierarchical shared-configuration tier in a tagged-storage-routing architecture: the param_config_* prefix side of the split (the other side being DynamoDB for high-frequency per-tenant reads). Path layout /config-service/{tenantId}/{service}/{parameter} enables IAM access control at the path level (e.g., per-tenant read restrictions) and bulk retrieval via GetParametersByPath.

  • Event-driven cache-refresh source: Parameter Store's built-in EventBridge integration means any parameter write fires a typed change event, which an invalidator Lambda can consume and push to live service instances without polling. This is the structural alternative to cache-TTL staleness for rapidly-changing config.

Why pair with DynamoDB

The AWS multi-tenant-config post frames it as two different access-pattern tiers rather than one redundant-tier choice:

Axis DynamoDB Parameter Store
Read frequency High (thousands/min) Low (mostly init)
Write frequency High Low
Data shape Per-tenant, composite-key Hierarchical shared
Bulk retrieval Per-key GetParametersByPath
Typical latency Single-digit ms Single-digit-to-tens-of-ms
Change events Streams Native EventBridge
Cost @ volume Per-request + storage Standard-tier free + API

Single-backend choices lose on one side: using DynamoDB for shared rarely-changing config is expensive and loses hierarchical organization; using Parameter Store for per-request tenant reads hits throttling on the parameter-read side and loses composite-key query shape.

Seen in

Caveats

  • Throttling at high read rates. Parameter Store's per-account API rate limits make it unsuitable as a hot-path per-request config source for high-traffic services. The multi-tenant-config pattern addresses this by caching at the service layer + pushing invalidations via EventBridge.
  • No rotation primitives for SecureString values (unlike Secrets Manager). Rotation requires a custom Lambda + scheduled run.
  • Hierarchical rename is not atomic — moving a path subtree requires delete + recreate, with a window where both exist.
  • SecureString is KMS-encrypted at rest; decryption is per-read — adds KMS API charges + latency on every read unless the caller caches the plaintext application-side (with care around where the plaintext lives).
Last updated · 200 distilled / 1,178 read