aws-s3-deployment v2.207: BucketDeployment broken for SSM StringListParameter source.

[asgard-bot]

Describe the bug

Previously, we worked around #22843 via SSM parameters, like:

stack 1:

const subnetIds = ourVpc.publicSubnets.map((subnet) => subnet.subnetId);
    new StringListParameter(this, `subnetIds-${props.env.account}-${props.env.region}`, {
      parameterName: subnetIdsParamName,
      stringListValue: subnetIds,
    });

stack 2:

    const subnetIdsParam = StringListParameter.fromStringListParameterName(
      this,
      `subnetIdsRead-${props.env.account}-${props.env.region}`,
      props.subnetIdsParamName,
    );

then. we'd reference subnetIdsParam.stringListValue in Source.jsonData.

However, as of version 2.207, this behavior is broken. While the SSM parameter is stored correctly, it is not resolved before the stack 2 template is deployed (token value is deployed in place of real value).

I believe this pattern may have been broken by #34916, which ironically solves the issue that prompted our use of the workaround.

Contact: tymcd@amazon.com

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

2.206.0

Expected Behavior

SSM parameter resolved in stack 2 and stored in json object via BucketDeployment.

Current Behavior

SSM parameter was not resolved (Token string deployed instead).

Reproduction Steps

• Create SSM stringlist parameter as shown above (string parameter appears to work).

• Create source.jsondata in another stack from stringlist parameter as show above.

• Create a bucket deployment that uses this json data included in the sources list.

• Deploy the stacks. Observe the value deployed in the bucket.

Possible Solution

No response

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

2.207.0

AWS CDK CLI version

2.1023.0

Node.js Version

18

OS

MacOS

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

taking a look

[pahud]

Reproduction Summary

I've successfully reproduced the regression in AWS CDK v2.207.0 where BucketDeployment with Source.jsonData() containing SSM StringListParameter.stringListValue no longer resolves tokens properly.

Key Evidence

1. Token Analysis Test - Shows that both direct and read StringListParameter values are being serialized as token strings (${Token[TOKEN.XX]}) instead of resolving to actual values like
   ["subnet-123", "subnet-456"].

2. Root Cause Identified - The issue is in the Source.jsonData() method where Stack.of(scope).toJsonString(obj) is not properly resolving SSM parameter tokens during synthesis.

3. Regression Confirmed - The issue was introduced by PR fix(s3-deployment): broken cross stack reference when using Source.data #34916 in version 2.207.0, which fixed cross-stack references but inadvertently broke SSM parameter resolution.

How to Test

• Full Deployment Test:

 npx cdk deploy SsmS3ReproStack
 aws s3 cp s3://[BUCKET_NAME]/config.json - | jq .

Reproduction Coce

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as s3deploy from 'aws-cdk-lib/aws-s3-deployment';
import * as ssm from 'aws-cdk-lib/aws-ssm';

export class MinimalReproStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create test data
    const testSubnets = ['subnet-12345', 'subnet-67890'];

    // Create SSM StringListParameter
    const ssmParam = new ssm.StringListParameter(this, 'TestParam', {
      parameterName: '/repro/subnets',
      stringListValue: testSubnets,
      description: 'Test parameter for reproduction'
    });

    // Read it back (this simulates the cross-stack scenario)
    const readParam = ssm.StringListParameter.fromStringListParameterName(
      this,
      'ReadParam',
      '/repro/subnets'
    );

    // Create S3 bucket
    const bucket = new s3.Bucket(this, 'ReproBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY,
      autoDeleteObjects: true
    });

    // Deploy JSON using the read parameter - this is where the issue occurs
    new s3deploy.BucketDeployment(this, 'ReproDeployment', {
      sources: [
        s3deploy.Source.jsonData('config.json', {
          subnets: readParam.stringListValue, // This should resolve to actual values but doesn't in v2.207.0
          expectedValues: testSubnets, // For comparison
          version: '2.207.0',
          issue: 'StringListParameter tokens not resolved in Source.jsonData',
          timestamp: new Date().toISOString()
        })
      ],
      destinationBucket: bucket
    });

    // Outputs
    new cdk.CfnOutput(this, 'BucketName', {
      value: bucket.bucketName,
      description: 'Check config.json in this bucket'
    });

    new cdk.CfnOutput(this, 'ParameterName', {
      value: ssmParam.parameterName,
      description: 'SSM parameter name'
    });

    new cdk.CfnOutput(this, 'ExpectedValues', {
      value: JSON.stringify(testSubnets),
      description: 'Expected subnet values in config.json'
    });

    new cdk.CfnOutput(this, 'VerificationCommand', {
      value: `aws s3 cp s3://${bucket.bucketName}/config.json - | jq .`,
      description: 'Command to check the deployed JSON'
    });
  }
}

Expected Behavior (v2.206.0 and earlier):

When checking the deployed config.json file:

aws s3 cp s3://[BUCKET_NAME]/config.json - | jq .

Expected Output:

{
  "subnets": ["subnet-12345", "subnet-67890"],
  "expectedValues": ["subnet-12345", "subnet-67890"],
  "version": "2.207.0",
  "issue": "StringListParameter tokens not resolved in Source.jsonData",
  "timestamp": "2025-08-04T19:45:00.000Z"
}

Actual Behavior (v2.207.0 - BROKEN):

Actual Output:

{
  "subnets": "${Token[TOKEN.22]}",
  "expectedValues": ["subnet-12345", "subnet-67890"],
  "version": "2.207.0", 
  "issue": "StringListParameter tokens not resolved in Source.jsonData",
  "timestamp": "2025-08-04T19:45:00.000Z"
}

v2.206.0 Deployment Results (WORKING VERSION)

Expected Output:

{
  "subnets": ["subnet-12345", "subnet-67890"],
  "expectedValues": ["subnet-12345", "subnet-67890"],
  "version": "2.206.0",
  "status": "Should work correctly",
  "timestamp": "2025-08-04T19:45:00.000Z"
}

Root Cause Confirmed

The issue occurs in the Source.jsonData() method:

// In source.ts line ~221
const serializedObj = Token.isUnresolved(obj) 
  ? Stack.of(scope).toJsonString(obj)  // This line fails for SSM parameters
  : JSON.stringify(obj);

What happens:

1. readParam.stringListValue is detected as an unresolved token ✅
2. Stack.of(scope).toJsonString() is called to resolve it ❌
3. Instead of resolving to actual values, it returns a token string ❌
4. The token string gets deployed to S3 literally ❌

The reproduction clearly shows that in v2.207.0, instead of getting actual subnet IDs in the deployed JSON, users get token strings, confirming the regression reported in issue #35145.

Workaround:

• Revert to CDK v2.206.0
• Or avoid using StringListParameter with Source.jsonData()

I'll bring this up to the team for immediate review.

[aemada-aws]

Thanks for reporting the bug. As a workaround, either downgrade the CDK version as Pahud mentioned or use the following workaround (adapt it to your code) which uses Source.data and cdk.Stack.of(this).toJsonString without downgrading:

 // Deploy JSON using the read parameter - this is where the issue occurs
    new s3deploy.BucketDeployment(this, 'ReproDeployment', {
      sources: [
        s3deploy.Source.data(
          'config.json',
          cdk.Stack.of(this).toJsonString({
            subnets: readParam.stringListValue,
            expectedValues: testSubnets,
            version: '2.207.0',
            issue: 'StringListParameter tokens not resolved in Source.jsonData',
            timestamp: new Date().toISOString(),
          })
        ),
      ],
      destinationBucket: bucket,
    });

Instead of :

 // Deploy JSON using the read parameter - this is where the issue occurs
    new s3deploy.BucketDeployment(this, 'ReproDeployment', {
      sources: [
        s3deploy.Source.jsonData('config.json', {
          subnets: readParam.stringListValue, // This should resolve to actual values but doesn't in v2.207.0
          expectedValues: testSubnets, // For comparison
          version: '2.207.0',
          issue: 'StringListParameter tokens not resolved in Source.jsonData',
          timestamp: new Date().toISOString()
        })
      ],
      destinationBucket: bucket
    });

After deploying a stack with this, i was able to see

{
  "subnets": [
    "subnet-12345,subnet-67890"
  ],
  "expectedValues": [
    "subnet-12345",
    "subnet-67890"
  ],
  "version": "2.207.0",
  "issue": "StringListParameter tokens not resolved in Source.jsonData",
  "timestamp": "2025-08-04T21:20:14.249Z"
}

in my s3 bucket, which validates it as a workaround for the latest CDK version.

We will work on a fix as soon as possible.

[related-issues-bot-for-aws]

Hi @asgard-bot,

Thanks for opening this issue! After reviewing the details, we found some other discussions that may be closely related:

Related Issues

• @aws-cdk/aws-s3-deployment: broken cross stack reference when used in Source.jsonData #22843: Both issues involve the aws-s3-deployment module's Source.jsonData() functionality with token resolution problems. The current issue specifically mentions using SSM parameters as a workaround for @aws-cdk/aws-s3-deployment: broken cross stack reference when used in Source.jsonData #22843, showing they share the same underlying token resolution issue. Both deal with dynamic values that need proper resolution before being stored in S3 buckets.

• aws-s3-deployment: Source.jsonData fails for certain types of deploy-time values #25504: Both issues involve token resolution problems in the aws-s3-deployment module's Source.jsonData() method. While aws-s3-deployment: Source.jsonData fails for certain types of deploy-time values #25504 focuses on CloudFormation functions like Fn::Join and Fn::Select not being supported, the current issue deals with SSM parameter tokens not being properly resolved. Both prevent successfully using deploy-time values in JSON files deployed to S3.

• aws-s3-deployment: Source.jsonData does not escape quotes #22661: Both issues concern token processing in the aws-s3-deployment module's Source.jsonData() method. aws-s3-deployment: Source.jsonData does not escape quotes #22661 involves quote escaping in unresolved tokens, while the current issue involves tokens not being resolved at all. Both stem from deficiencies in how Source.jsonData() handles tokens during the rendering process, preventing proper JSON generation with dynamic values.

This message was generated automatically to help connect related conversations and improve discoverability

Please react with 👍 or 👎 to let us know if this response was helpful!

Thank you for helping improve CDK! 🙌