Introduction
Hi, I'm miruky.
AWS Systems Manager Parameter Store creates a new version each time a parameter value changes. Reapplying an earlier value therefore moves the version number forward; it does not turn the current version back to an old number.
I tested that behavior with one Standard String parameter. The value starts as INFO in version 1, changes to DEBUG in version 2, and returns to INFO in version 3. Each state is verified in the AWS Console before the next change.
The two values are ordinary configuration tokens, not secrets. I did not use SecureString, a KMS key, an endpoint, a password, or an account-specific value. The current AWS documentation lists Standard parameters at no additional charge; Advanced parameters and higher-throughput interactions have different pricing.
1. Create a non-secret Standard parameter
Parameter Store parameters exist only in the Region where they are created. I kept this run in us-east-1 and recorded the Regional context before creating anything.
The page still shows United States (N. Virginia), and Start to use Parameter Store confirms that the Region contained no parameters before this run. That empty state also proves that the generated name miruky-isdeziwttyxgqaoc was not already in use.
Choose Create parameter and enter the generated name. Keep the tier on Standard and the type on String. Standard is important here because Advanced parameters can incur charges and cannot later be downgraded in place.
The upper form visibly keeps Standard and String selected for the generated name. I then moved to the lower part of the same form to enter the value.
The lower form shows String, text, and INFO, while the Tags panel reports no tags. Plain-text parameters must not contain a credential or any other secret. I created the parameter and opened its Overview tab.
Overview confirms the current value INFO and version 1. There is only one version at this point, so no rollback behavior has occurred yet.
2. Create an unwanted version 2
Choose Edit and replace INFO with DEBUG. The form keeps the parameter tier and type fixed while allowing the current value to change.
The Value field now contains DEBUG while Standard and String remain fixed. I saved the change, reopened the parameter, and checked Overview.
Overview now shows DEBUG as version 2. This is the deliberately unwanted state, and an unversioned read now resolves to it.
3. Confirm that History retained both versions
Open the History tab. The current Console lists versions 2 and 1 as separate rows with their own modification times. The earlier version still exists; the update did not erase it.
One current-Console detail matters: this History table shows version metadata, not the historical value itself. For this console-only run, I use the INFO value already recorded on the version-1 Overview page. If the earlier value is unknown, retrieve the required version with a version-aware API, CLI, SDK, or SSM document instead of guessing it.
History also has no operation that changes the latest pointer back to version 1. Making the known earlier value current requires one more saved edit.
4. Restore the value as version 3
I opened the parameter editor and entered the previously recorded value.
The Value field is back to INFO, while the immutable type remains String. I saved this change and reopened Overview.
Overview now shows INFO with version 3; the rollback is a forward version change. I returned to History once more to check the retained rows.
The table retains 3, 2, and 1 as separate version rows. Version 2 remains part of the audit trail instead of disappearing when INFO becomes current again.
An unversioned parameter read now resolves to the latest version, which is version 3. A version-aware client that explicitly requests version 2 remains pinned to the retained version-2 value; restoring the latest value does not rewrite an older version.
Wrap-up
The rollback in this Console run is an auditable forward change. Version 1 records the original INFO, version 2 records the temporary DEBUG, and version 3 makes INFO current again.
For production configuration, decide whether consumers follow the latest value, an explicit version, or a movable parameter label. That reference choice determines whether creating a restored current version changes application behavior.
Thanks for reading this far.
See you in the next one.
Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.
Top comments (0)