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/progressive-configuration-rollout).

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

  • sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — the param_config_* branch of a Strategy-Pattern-backed tagged-storage-routing config service. Stores /config-service/{tenantId}/{service}/{parameter} path-structured shared parameters (API endpoints, database connection strings, region-specific settings). Changes emit EventBridge events consumed by an invalidator Lambda that pushes updates to live ECS Fargate Config Service instances over gRPC — eliminating cache-TTL staleness for the shared-config tier.

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 · 766 distilled / 2,225 read