cli: cdk import fails on stacks containing non-ASCII characters (GetTemplate mangling)

[adriantaut]

Describe the bug

cdk import fails on any stack whose deployed template contains a non-ASCII character in a resource property, even when the local code is byte-identical to what is actually deployed.

Root cause: cdk import builds its import template from the deployed template (CloudFormation GetTemplate) plus the resources being imported. GetTemplate is lossy — it replaces non-ASCII characters with a literal ASCII ?. CDK therefore submits a template in which an untouched resource's property differs from what CloudFormation actually holds, and CloudFormation rejects the IMPORT change set:

You have modified resources [<LogicalId>] in your template that are not being imported.
Update, create or delete operations cannot be executed during import operations.

The named resource has not been modified by the user at all — the only difference is — (U+2014) vs ?.

This is the same CloudFormation mangling already known to cdk diff, which has masked it since aws/aws-cdk#25912 ("Omitted N changes because they are likely mangled non-ASCII characters. Use --strict to print them."). That masking was never applied to the cdk import code path, so the problem is invisible in cdk diff and then blocks cdk import with an error that points at an innocent resource.

The affected property in our case is AWS::IAM::ManagedPolicy.Description, which is create-only — so it cannot be "fixed" in place to work around the issue. Changing it forces a replacement, and since ManagedPolicyName is also create-only and fixed, replacement fails with EntityAlreadyExists. Affected users have no remediation path within CDK.

Expected Behavior

cdk import succeeds. A property whose deployed value differs from the local value only by GetTemplate's non-ASCII mangling should be treated as unchanged — the same way cdk diff has treated it since aws/aws-cdk#25912.

Current Behavior

cdk import fails during change-set creation:

MyFoundationStack: creating CloudFormation changeset...

 ❌  MyFoundationStack failed: CloudFormationServiceException [ValidationError]:
 You have modified resources [MyScopedPolicy1A2B3C4D] in your template that are not
 being imported. Update, create or delete operations cannot be executed during import operations.

Verification that the resource is genuinely unmodified:

• Local synthesized template: "Description": "Scoped IAM access for the app production role — App resources only." (U+2014)
• aws iam get-policy: returns the same string, with U+2014 intact — the live resource is correct
• aws cloudformation get-template: returns "Scoped IAM access for the app production role ? App resources only." (?, 0x3F)
• cdk diff reports no change to this resource, printing only Omitted 1 changes because they are likely mangled non-ASCII characters.

Editing the local source to contain a literal ? does not help — the published import template is byte-identical either way, since the local source is not an input to it. That is what pinned the cause to the GetTemplate round-trip.

Reproduction Steps

1. Synthesize a stack containing a resource with a non-ASCII character in a string property, e.g.:

   new iam.ManagedPolicy(this, 'Policy', {
     managedPolicyName: 'my-policy',
     description: 'Scoped access — resources only.',   // U+2014 EM DASH
     statements: [ /* ... */ ],
   });

2. cdk deploy.

3. aws cloudformation get-template --stack-name <stack> — the description comes back with ? instead of —.

4. Add to the same stack a resource that already exists in the account and is intended for import (any importable type; we used an AWS::SNS::Topic plus its AWS::SNS::Subscription).

5. cdk import <stack> and supply the physical identifier when prompted.

6. Change-set creation fails with the ValidationError above, naming the policy — a resource not involved in the import.

Possible Solution

Apply the mangling-aware comparison introduced in aws/aws-cdk#25912 to the import path: when building the import template, treat a deployed value that is the mangled form of the local value as unchanged. Alternatively, construct the import template from the synthesized template (which retains the true characters) rather than from GetTemplate output.

Workaround for anyone hitting this: bypass cdk import and submit the change set directly, using the synthesized template as the base, so the true characters reach CloudFormation.

aws s3 cp import-template.json s3://<bucket>/import-template.json
aws cloudformation create-change-set --stack-name <stack> \
  --change-set-name import-x --change-set-type IMPORT \
  --capabilities CAPABILITY_NAMED_IAM \
  --template-url https://<bucket>.s3.<region>.amazonaws.com/import-template.json \
  --resources-to-import '[{"ResourceType":"AWS::SNS::Topic","LogicalResourceId":"...","ResourceIdentifier":{"TopicArn":"..."}}]'
aws cloudformation execute-change-set --stack-name <stack> --change-set-name import-x

This succeeded immediately on the same stack where cdk import failed, with the change set containing only the two intended Import actions — confirming the deployed state was never actually divergent. Imported resources need an explicit DeletionPolicy in that template.

Additional Information/Context

The underlying GetTemplate behaviour is a CloudFormation API limitation, reported and still open:

• API: GetTemplate/DescribeStacks do not properly return utf-8 characters aws-cloudformation/cloudformation-coverage-roadmap#814 (Mar 2021) — GetTemplate/DescribeStacks do not properly return UTF-8 characters
• GetTemplate API does not support non-ASCII characters aws-cloudformation/cloudformation-coverage-roadmap#1220 (Jun 2022) — GetTemplate API does not support non-ASCII characters

Related CDK history:

• [cli] cdk diff always reports diff if resource has non-ASCII characters aws-cdk#10523 — cdk diff always reports diff if resource has non-ASCII characters
• chore: hide diffs of mangled unicode strings aws-cdk#25912 — Hide diffs of mangled Unicode strings in cdk diff (merged Jun 2023; added the --strict flag and the "Omitted N changes" message)
• (cdk diff): Unicode characters not properly recognised by the cdk diff aws-cdk#26703 — Unicode characters not properly recognised by cdk diff (follow-on)

Since CloudFormation is unlikely to fix GetTemplate soon, mirroring aws/aws-cdk#25912's approach in the import path seems the practical fix. Filing this because the diff side was mitigated in 2023 while import still fails, and the error message gives no indication that character encoding is involved — it names an unrelated resource, which makes it very hard to diagnose.

AWS CDK Library version (aws-cdk-lib)

2.267.0

AWS CDK CLI version

2.1139.0 (build d51353e)

Node.js Version

v24.5.0

OS

macOS 26.5.2 (arm64)

Language

TypeScript

[pahud]

Thanks for the exceptionally thorough report — the byte-level comparison and the literal-? experiment made this straightforward to confirm. I was able to reproduce this end-to-end on CDK CLI 2.1139.0 (us-east-1): deployed a stack with an em dash (U+2014) in an AWS::IAM::ManagedPolicy description, confirmed get-template returns ? while iam get-policy returns the true character, then ran cdk import for an out-of-band SNS topic — change-set creation failed with exactly the error you reported, naming the untouched policy. Notably, the import's own pre-flight diff even prints Omitted 1 changes because they are likely mangled non-ASCII characters before going on to submit the mangled template anyway.

The import template is indeed built from the deployed template as returned by GetTemplate, with only the imported resources added on top — no de-mangling happens anywhere in that path:

aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/api/resource-import/importer.ts

Lines 304 to 330 in c1d93ab

	private async currentTemplate(): Promise<any> {
	if (!this._currentTemplate) {
	this._currentTemplate = await this.cfn.readCurrentTemplate(this.stack);
	}
	return this._currentTemplate;
	}
	/**
	* Return the current template, with the given resources added to it
	*/
	private async currentTemplateWithAdditions(additions: ImportableResource[]): Promise<any> {
	// Build the IMPORT change-set template from a *copy* of the deployed template. We must not
	// mutate the cached deployed template: it is also referenced as the "old template" by the
	// diff formatter returned from `discoverImportableResources`, and `fullDiff` (which it runs)
	// already had a history of mutating its inputs. Reusing/mutating the cached object risks
	// leaking changes - the import additions, or normalizations such as sorted `DependsOn`
	// arrays - into the submitted change set, which CloudFormation rejects as modifications to
	// resources that are not being imported. See https://github.com/aws/aws-cdk-cli/issues/1575.
	const template = structuredClone(await this.currentTemplate());
	if (!template.Resources) {
	template.Resources = {};
	}
	for (const add of additions) {
	template.Resources[add.logicalId] = add.resourceDefinition;
	}

Meanwhile the compensation from aws/aws-cdk#25912 lives in cloudformation-diff as mangleLikeCloudFormation() and is only consumed by the diff formatter — which is exactly why cdk diff stays quiet while cdk import fails.

From my view, your first suggested fix is the right one: when building the import template, compare each deployed string against mangleLikeCloudFormation(localValue) and substitute the local value on a match, so only mangling-artifacts are healed and real modifications still fail loudly. Rebuilding from the synthesized template would also work (your manual change-set proves it), but it has more edge cases around --force/non-addition imports.

One housekeeping note: cdk import lives in the aws/aws-cdk-cli repo (@aws-cdk/toolkit-lib), so this issue will likely be transferred there.

Until a fix ships, the workaround you documented — creating the IMPORT change set directly with the synthesized template — is the best available path, and it's great that you included it for others who hit this.