[Update] 13 New Data Types Including integer and json Have Been Added to AWS Systems Manager Parameter Store

Hello. I'm Takeda from the Service Development Department.

On November 5, 2026, 13 new data types that can be assigned to AWS Systems Manager Parameter Store parameters were added. If you assign a type, values that don't match the type are rejected at the time of PutParameter.

https://aws.amazon.com/about-aws/whats-new/2026/11/aws-ssm-parameter-store-allows-organization-validation-with-new-data-types/

Until now, the available DataType values were only the default text, which performs no validation, aws:ec2:image for AMI IDs, and aws:ssm:integration for Automation webhooks. Format checks for port numbers and IP addresses had to be written on the application side or handled with a regular expression in AllowedPattern. This time I tried all 13 types from the AWS CLI.

Newly added data types

The 13 types listed in the user guide are as follows.

All 13 added types also support SecureString.

https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-store-data-types.html

Test environment

• AWS CLI 2.36.30
• Tokyo Region (ap-northeast-1)
• Tested on November 9, 2026

Values that don't match the type are rejected by PutParameter

All you need to do is add --data-type when calling put-parameter.

aws ssm put-parameter --name /myapp/port --type String --data-type integer --value 443

If you pass a value that doesn't match the type, you get a ValidationException.

An error occurred (ValidationException) when calling the PutParameter operation: The parameter value is not a valid integer. A value must be an optional minus sign followed by digits, with no leading zeros, no plus sign, no decimal point and no whitespace.

For the 10 types available in the standard tier, I tried values that pass and values that are rejected. The results are as follows.

All results matched the documentation. The error messages even tell you the reason. For an out-of-range integer, it returned "outside the supported integer range". For an underscore in hostname, it says "It contains an underscore". For Japanese domain names, it guides you to write them in punycode with "Give an internationalized name in punycode (xn--)."

Formats with a display name such as Mary <mary@example.com> for email were rejected because they contain whitespace.

The parameter value is not a valid email address. It contains whitespace or a control character.

When you get the type name wrong, it tells you that type names are all lowercase.

The following data type is not supported: int. (Data type names are all lowercase.)

url, json, and jsonc require the advanced tier

The results of testing in the advanced tier are as follows.

For a URL containing a password, the message urges you to use Secrets Manager.

Specifying json in the standard tier results in the following error. It was the same when --tier was omitted.

The json data type is only supported for advanced parameters.

When I added --tier Intelligent-Tiering, the parameter was created in the advanced tier. Advanced-tier parameters incur storage charges, so if you only want to use the json type, check the pricing first.

StringList and SecureString

For StringList, each element is validated, and the message shows which element is invalid.

aws ssm put-parameter --name /myapp/notify-to --type StringList --data-type email \
  --value 'a@example.com,bad'

Element 2 of the StringList: The parameter value is not a valid email address. It has no @.

If you specify a type that doesn't support StringList, the creation itself fails.

The integer data type is not supported for the following input type: StringList

Validation works the same way for SecureString. The message when I entered S3cretValue with the integer type was the same as for String. The message does not include the value.

If you omit the type when overwriting, the existing type is inherited

The type of an existing parameter can be changed later. The results of operations on a single parameter, in order from the top, are as follows.

Step 4 deserves attention. If you omit --data-type when overwriting, the type does not revert to the default text; the existing integer is inherited and validation continues.

The type not being dropped when the value changes is the safe behavior. When you want to remove validation, explicitly specify --data-type text.

When changing to an advanced-only type such as json, it fails unless you also specify --tier Advanced.

Values are returned as strings when retrieved

Even when you retrieve a parameter of the integer type, the value is a string.

aws ssm get-parameter --name /myapp/port \
  --query 'Parameter.{Value:Value,Type:Type,DataType:DataType}'

{
    "Value": "443",
    "Type": "String",
    "DataType": "integer"
}

The conversion to a number on the application side is still necessary, as before. All the type guarantees is that the value can be converted to a number.

With describe-parameters, you can filter by type.

aws ssm describe-parameters --parameter-filters Key=DataType,Values=json,jsonc

Passing a nonexistent type name resulted in InvalidFilterValue.

Summary

All 13 types were validated according to the boundary values described in the documentation. You can use them just by adding --data-type to an existing put-parameter, and validation is not dropped even if you omit the type when overwriting.

Port number and IP address checks that you used to write with AllowedPattern regular expressions look like they can be replaced with types while staying in the standard tier.

I hope this is helpful to someone.

References

• Parameter data types in Parameter Store
• AWS Systems Manager Parameter Store now allows organization and validation with built-in data types