Backing Up AWS Systems Manager Parameter Store Across Accounts and Regions
How I built an open-source AWS CDK solution to capture parameter changes, store encrypted backups in a central account, and back up existing parameters through an on-demand reconciliation workflow.
Production infrastructure requires more than reliable deployments. It also needs a recovery strategy for the configuration those deployments depend on.
When we needed to back up AWS Systems Manager Parameter Store across multiple accounts and Regions, we found a gap: Parameter Store was not covered by native AWS Backup integration.
That led me to build AWS SSM Parameter Store Backup —an open-source AWS CDK application that stores encrypted parameter backups in a central AWS account.
What the solution does
The application supports a single account or multiple configured accounts and Regions. It provides:
- Event-driven backups for parameter create and update operations.
- Centralized storage in an encrypted, versioned S3 bucket.
- Separate records for captured parameter versions.
- Deletion records that preserve previous backups.
- An on-demand workflow for initial backups and reconciliation.
- Dead-letter queues, CloudWatch alarms, and SNS notifications.
- Configurable deployment through AWS CDK.
How the architecture works
In the central account, an EventBridge rule captures native Parameter Store change events and sends them to SQS. A Lambda function processes the queue, retrieves the parameter value, and writes a JSON backup record to S3.
For additional source accounts and Regions, spoke stacks forward event metadata to the central EventBridge bus. The central Lambda then assumes a dedicated read role in the source account to retrieve the parameter.
Parameter values do not travel through EventBridge. Events carry metadata; the backup function retrieves sensitive values through scoped permissions.
This gives local and spoke parameters a common backup pipeline while keeping storage and monitoring centralized.
Keeping backup history
Backup objects are organized by source account, Region, parameter path, and version:
1
2
3
ssm-backups/<account-id>/<region>/<parameter-path>/<version>.json
ssm-backups/<account-id>/<region>/<parameter-path>/latest.json
ssm-backups/<account-id>/<region>/<parameter-path>/DELETED-<timestamp>.jsonVersion records preserve captured values, and
latest.json points to the latest captured state.When a parameter is deleted, the application writes a deletion tombstone instead of removing its previous backups. This preserves the history needed to investigate or recover from accidental deletion.
Backing up existing parameters
An event pipeline alone does not capture parameters that already exist and never change.
The application includes an operator-triggered Step Functions reconciliation workflow. It lists parameters beneath the configured path, writes a manifest, and queues them through the same backup function used for events.
You can use this workflow to create an initial backup or reconcile current state after a suspected missed event. It is not scheduled automatically in the current implementation.
Security considerations
The backup bucket blocks public access, requires TLS, and uses a customer-managed KMS key for encryption.
Parameter access is restricted to a configured path, such as
/application/. Spoke accounts use dedicated read roles, with explicitly configured customer-managed KMS keys where needed to decrypt SecureString parameters.One important detail: backup records contain decrypted parameter values inside encrypted S3 objects. Access to the backup bucket and its encryption key therefore requires the same care as access to the original parameters.
The application also encrypts operational logs and runs
cdk-nag during synthesis to support infrastructure security review.Deployment and verification
Deployment settings are maintained in
config/ssm-backup-config.ts. Configure your central account, Region, parameter scope, optional spokes, tags, and notification recipients before deploying.Deploy the central stack first, followed by each spoke stack using the appropriate account credentials. The README provides the full instructions.
After deployment, verify the complete pipeline:
- Create or update a non-sensitive test parameter.
- Confirm that its backup record and
latest.jsonappear in S3. - Repeat the check in each configured spoke.
- Delete the test parameter and verify the deletion record.
- Confirm notification subscriptions and inspect the dead-letter queues.
Understanding the limits
AWS emits Parameter Store events on a best-effort basis . The backup function also reads the current parameter value when it processes a message. Rapid updates can therefore cause intermediate versions to be missed.
Reconciliation helps capture current values, but it cannot recover a parameter deleted before any backup captured it.
This is an event-driven backup solution, rather than a guarantee that every change is preserved. It collects backups from multiple source Regions into the configured central Region; it does not automatically recreate live parameters in another Region.
Restoration should be planned and tested separately against your recovery requirements.
Alignment with AWS Well-Architected principles
The architecture supports several AWS Well-Architected principles by making configuration backups more secure, observable, and repeatable.
Operational Excellence
AWS CDK makes deployment repeatable and keeps infrastructure configuration in version control.
Security
Encrypted storage in a dedicated account separates backups from source workloads. Scoped IAM roles limit parameter access, and parameter values do not travel through EventBridge. S3 public access blocking, TLS enforcement, and KMS encryption protect sensitive backup data.
Reliability
Captured version history and deletion records preserve recovery data after configuration changes or accidental deletion. SQS buffers received events, while dead-letter queues retain failed work for investigation and reprocessing. On-demand reconciliation complements event-driven capture by backing up current values.
Performance Efficiency
Managed services process backup work without a dedicated, continuously running server. A shared central pipeline handles parameters from configured accounts and Regions, while SQS decouples event arrival from processing.
Cost Optimization
Event-driven processing avoids continuously polling every parameter. Configurable parameter paths let teams back up the configuration they need, while centralized storage simplifies oversight. Actual costs depend on change volume, reconciliation frequency, KMS requests, logs, and retained history.
Sustainability
The architecture avoids dedicated, always-running backup compute. Event-driven processing and scoped parameter selection reduce unnecessary work, although the solution does not measure environmental savings.
Together, these choices provide a practical foundation for configuration recovery. They support a Well-Architected review, while recovery objectives, retention requirements, restore testing, and access controls remain specific to each organization.
Feedback and contributions are welcome!
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article