Amplify Backend Gen1 → Gen2 Migration (Developer Preview)

[iliapolo]

Amplify team has launched a beta version of a flavor of the Gen1 CLI that adds support for migrating Gen1 backend environments to Gen2.

Caution

The migration tool discussed here is in early stages of development and SHOULD NOT be
executed on any production or mission critical environments. Only run it for testing
purposes on environments you can afford to delete.

Your feedback will significantly help the team improve and stabilize the tool. We welcome and encourage any feedback on the migration process:

• Success stories
• Failure stories
• General Questions
• Anything you want

Get started by following our migration guide. We are eager to hear what you think and incorporate your feedback in the upcoming versions!

Thanks.

[iliapolo]

Heads up folks we identified a code generation bug: #14492

It pretty elusive at the moment and doesn't happen on every app. If this happens to you, please let us know and share your setup.

Thanks!

[iliapolo]

Fixed

[jamilsaadeh97]

Is there any reason why Flutter is not supported? Or is it untested yet

[iliapolo]

@jamilsaadeh97

if I went ahead and tried the tool, would those features be overwritten/removed or can I manually reference or add them in the gen 2 code without losing them?

Analytics and notifications would not be code generated so your Gen2 environment will be missing those. You can manually add them in using some fairly complex CDK code - but since they also need special handling in the refactor phase i'm afraid you won't be able to complete migration right now.

The other features you mentioned (auth trigger, guess access) should be possible to compensate with some manual editing, but I can't say exactly what that would look like right now.

Im happy to share more insights into my current stack if you want.

Anything you can share will be really helpful. If you have the exact CLI commands you ran to setup your app that would be really great because we could reproduce your setup.

Im also intersted in:

• Does your flutter code live in the same repo (and folder) as your amplify directory?
• How are you deploying your Gen1 environment?
• How are you consuming the amplifyconfiguration.json file in your flutter code?

Thanks!

[jamilsaadeh97]

Analytics and notifications would not be code generated so your Gen2 environment will be missing those. You can manually add them in using some fairly complex CDK code - but since they also need special handling in the refactor phase i'm afraid you won't be able to complete migration right now.

So I can't use this to reference the existing analytics and notifications resources without losing them when deploying the newly migrated gen2 app?

import { defineBackend } from "@aws-amplify/backend"

const backend = defineBackend({})

backend.addOutput({
  analytics: {
    amazon_pinpoint: {
      aws_region: "<your-aws-region>",
      app_id: "<your-pinpoint-app-id>",
    },
  },
})

This is coming from the docs

If you have the exact CLI commands you ran to setup your app that would be really great because we could reproduce your setup.

I will try to provide the exact CLI commands for my setup. This Amplify app is fairly big and grew a lot over the last 4-5 years so I will need to recreate the gen 1 app from scratch and note the commands. Unless there's an easier way I don't know about?

Does your flutter code live in the same repo (and folder) as your amplify directory?

It used to, but I changed it to be an isolated repo for the backend, and multiple frontends (each living alone) connected to the same backend. I pull the changes with amplify pull --appId xxx --envName xxx in each frontend repo when needed.

How are you deploying your Gen1 environment?

If you mean my flutter app, I deploy it to the App Store and Play Store, not hosted using Amplify Hosting since we don't have a web app yet, just a mobile app. And if you mean the Amplify environment, manually using amplify push

How are you consuming the amplifyconfiguration.json file in your flutter code

Since I specified in the cli that it's a flutter app, the gen 1 cli generates an amplifyconfiguration.dart and not a .json to be consumed by the Amplify Flutter library using Amplify.configure().

Please let me know if I missed some info to provide, will be more than happy to provide more in order for you guys to gain as much insights as possible.

[jamilsaadeh97]

To give a general idea about the setup:

Auth

• Login using email or phone number
• Guest access enabled
• Required attributes are first name, last name, phone number, email, birthdate
• We have one group called "Partners"
• Lambda triggers: Pre signup, Post Confirmation, Custom Message
• No Admin Apis

Api

• Default auth mode: Cognito User Pool
• Additional auth mode: IAM
• DynamoDB lambda triggers on different models

Storage

• Content
• Restricted access to Auth(read, create)/Guest(read) users
• Lambda trigger

Function

Multiple lambda functions with different access to Cognito, DynamoDB, S3, Pinpoint

And finally Pinpoint analytics and notifications.

This is in a nutshell, it should give a pretty close setup.

[iliapolo]

So I can't use this to reference the existing analytics and notifications resources without losing them when deploying the newly migrated gen2 app?

import { defineBackend } from "@aws-amplify/backend"

const backend = defineBackend({})

backend.addOutput({
  analytics: {
    amazon_pinpoint: {
       aws_region: "<your-aws-region>",
       app_id: "<your-pinpoint-app-id>",
    },
  },
})

You could. But there are a few issues with that:

• Your pinpoint resources won't be managed by the new Gen2 environment (i.e the underlying CloudFormation stack) - so you won't be able to evolve them going forward via the Gen2 code.
• You mentioned your functions access pinpoint - so you'd need to manually edit the generated Gen2 code to configure that access (permissions and env variables).
• Eventually you'd also want to decommission your old Gen1 environment without deleting these pinpoint resources.

For all of this to work, the migration tool needs to code generate the right CDK code and perform a CloudFormation refactor so that these resources will be owned by the Gen2 stack. This is currently not supported.

So yeah you could do that for now for testing purposes but its not a long term solution. Unless your pinpoint resources are managed externally from your Gen1 environment - are they?

And if you mean the Amplify environment, manually using amplify push

Yeap thats what I meant. So after you migrate to Gen2 - do you have an idea on how you'd like to deploy the app?

• Will you leverage Fullstack branch deployments even though you don't have a webapp?
• Or will you run npx ampx pipeline-deploy --branch <your-branch> --app-id <your-app-id> from your own external pipeline?

This is in a nutshell, it should give a pretty close setup.

Thank you! This helps a lot.

[jamilsaadeh97]

So yeah you could do that for now for testing purposes but its not a long term solution. Unless your pinpoint resources are managed externally from your Gen1 environment - are they?

You're right, the issues you mentioned are valid for us. No they are not managed externally.

Yeap thats what I meant. So after you migrate to Gen2 - do you have an idea on how you'd like to deploy the app?
Will you leverage Fullstack branch deployments even though you don't have a webapp?
Or will you run npx ampx pipeline-deploy --branch <your-branch> --app-id <your-app-id> from your own external pipeline?

I've played around with Gen 2 a while ago, and I think at first I will be deploying using the command. In the future I might leverage the fullstack branch deployment. I also saw that it's possible with a dummy frontend (empty index.js). This way I can commit and push and the backend will be deployed automatically. In the future, when we will develop a web app, the whole thing will be ready and we just replace the frontend part.

Thank you!

[OperationalFallacy]

I didn't see anything mentioned about DataStore alternatives? Imho, that's a big deal for the app functionality.

I would also try to have something like a high level map of features of gen1 to gen2 from admin perspective, otherwise it's easy to get lost how things function or what's their purpose, or where things managed.

I wrote about migration path a while back from that point of view
https://thecloudtimes.substack.com/p/aws-amplify-migration-from-gen1-part

[OperationalFallacy]

clear mapping of how the migration tool will choose to implement each Gen1 feature in Gen2?

yes, this. I think you already maintain nice list on the doc website on features parity.

In addition to that, what I meant "admin perspective" is how development and deployments flows change. Would allow teams plan the migration better.

For example, sharing outputs files between be and front-end was a big friction point for me on a mono repo setup, had to figure out how to package and share it properly. The UI/forms flows changed, too.

[iliapolo]

For example, sharing outputs files between be and front-end was a big friction point for me on a mono repo setup

Can you elaborate on this?

[OperationalFallacy]

Outputs is backend generated, from deployed resources and part of the deployment workflow. The backend code will need to consume the file to access deployed properties (in Lambda for example) in the repos that beyond toy projects. That's a first self-feeding loop.

In addition, the outputs file is also directly consumed by front-end. Also, outputs file is an integration point for the custom props.

In a repo setup, with backend and front-end separated, workflow to share output updates become none trivial. And is very different from gen1.

[iliapolo]

In Gen2 you can generate the amplify_outputs.json file using this command:

npx ampx generate outputs --app-id <app-id> --branch <branch-name>

This file is the Gen2 equivalent of the Gen1 amplifyconfiguration.json and client libraries can work with both. Is that not sufficient to provide a similar workflow to Gen1?

The backend code will need to consume the file to access deployed properties (in Lambda for example) in the repos that beyond toy projects

Do you mean application backend code? or other infra code? If you can give a concrete example that would be great. Thanks!

[OperationalFallacy]

In backend I do something like below.
It lets me decouple Lambda code from the Amplify helpers.
So I can override service layer based on the outputs config with local creds loaders, override amplify client for unit testing, guard setup so envs doesn't get mixed up

import { parseAmplifyConfig } from "@aws-amplify/core/internals/utils";
import { fromNodeProviderChain } from "@aws-sdk/credential-providers";
import { Amplify, type ResourcesConfig } from "aws-amplify";
import { generateClient } from "aws-amplify/api";
import { Effect, Schema as S } from "effect";
import outputs from "../../../amplify_outputs.json";
import type { Schema } from "../../../data/resource";

export const AmplifyOutputsSchema = S.Struct({
	custom: S.Struct({
		env: S.Struct({
			name: S.String,
		}),
		events: S.Struct({
			url: S.String,
		}),
	}),
});

export type AmplifyRuntimeService = {
	readonly client: ReturnType<typeof generateClient<Schema>>;
	readonly eventsEndpoint: string;
};

export class AmplifyRuntime extends Effect.Service<AmplifyRuntime>()(
	"AmplifyRuntime",
	{
		effect: Effect.gen(function* () {
			const decodedOutputs =
				yield* S.decodeUnknown(AmplifyOutputsSchema)(outputs);
			const amplifyConfig: ResourcesConfig = parseAmplifyConfig(outputs);
			const credentialsProvider = fromNodeProviderChain();

			Amplify.configure(amplifyConfig, {
				Auth: {
					credentialsProvider: {
						getCredentialsAndIdentityId: async () => ({
							credentials: await credentialsProvider(),
						}),
						clearCredentialsAndIdentityId: () => {},
					},
				},
			});

			yield* Effect.logDebug("Amplify config loaded");

			const eventsEndpoint = decodedOutputs.custom.events.url;
			const runtimeService: AmplifyRuntimeService = {
				client: generateClient<Schema>({ authMode: "iam" }),
				eventsEndpoint,
			};

			return runtimeService;
		}),
		dependencies: [],
	},
) {}

export const AmplifyRuntimeLive = AmplifyRuntime.Default;

The outputs file gets compile packaged, so front-end can import it from the same location and load it in a similar way with overrides it needs.

[hisham]

Thanks for the update. I haven't tested yet, but off the top of my head we use lambda layers heavily (well we just have 1 layer but it's shared with multiple lambdas). So I think we can't test this migration until lambda layers is supported in gen 2?

[iliapolo]

@hisham even though building layers isn't directly supported in Gen2, you can use CDK for that and hook it up into defineFunction.

• https://docs.amplify.aws/react/build-a-backend/functions/add-lambda-layers/
• https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda.LayerVersion.html

[iliapolo]

Update that we released a new version of the tool (now in developer preview as part of the Gen1 CLI) as well as the migration guide, which is now in the official amplify docs: https://docs.amplify.aws/react/start/migrate-to-gen2/

Give it a try and let us know!

[aaronjwhipple87]

refactor: CloudFormation refuses ExecuteStackRefactor — "Stack [...] was updated since this refactor was created" (deterministic, 3 attempts incl. attended)

Setup

• Gen 1 CLI 14.5.1 (latest), macOS; region us-west-2
• Gen 1 env locked (lock --skip-validations --yes, only benign tag/trust-policy drift); categories: auth (user pool + identity pool + 2 clients), storage (S3), api (AppSync, tables shared via migratedAmplifyGen1DynamoDbTableMappings), 2 functions
• Gen 2 branch deployed with npx ampx pipeline-deploy from GitHub Actions (backend 1.11.3), Steps 1–6 of the guide completed and verified against live data

Command — amplify gen2-migration refactor --to amplify-<appId>-gen2main-branch-<hash>

All validations pass (Environment Locked, Assessment, Stack status ×4, Deletion Protection ×4, Stack Unchanged ×4). The plan is as expected (auth: prepare source/target, move 5 placeholder resources Gen 2 → holding, move 5 Gen 1 resources → Gen 2; storage: same shape with 1 bucket).

What happens, every time

[auth/...] Refactoring <gen2-auth-nested-stack> → <gen2-auth-nested-stack>-holding
[auth/...] Creating stack refactor: ...
[auth/...] Waiting for stack refactor creation to complete: <StackRefactorId>
🛑 Failed: ValidationError: You cannot execute the refactor [<StackRefactorId>]. Stack [arn:aws:cloudformation:us-west-2:<account>:stack/amplify-<appId>-gen2main-branch-<hash>-auth179371D7-12KDVELQQPKWH/fa794850-...] was updated since this refactor was created.
🛑 Stack '<gen2-auth-nested-stack>-holding' returned an empty template

The refactor itself reaches Status=CREATE_COMPLETE, ExecutionStatus=AVAILABLE (never OBSOLETE); the destination holding stack is created in REVIEW_IN_PROGRESS ~2 s after the refactor; ExecuteStackRefactor is then refused.

Attempt	Prepare step	Last API call on the Gen 2 auth stack before CreateStackRefactor	Create → Execute	Result
1 (--yes)	change sets executed on both auth stacks	ExecuteChangeSet 26 s earlier (stack UPDATE_COMPLETE 26 s before)	13 s	refused
2 (--yes)	skipped ("didn't contain changes")	DeleteChangeSet 66 s earlier	11 s	refused
3 (attended, waited >5 min at the confirmation prompt)	skipped	plan-phase CreateChangeSet/DeleteChangeSet several minutes earlier	~10 s	refused

Refactor ids: 5e6808f4-134a-4fd8-9bd8-f1328b045ee6, 8538d884-fe20-40dc-ac8c-810657f9ea90, 1dfcaec1-3d6c-42ec-92e6-797ece0f1b30 (2026-09-09, 17:38 / 17:53 / 18:23 UTC).

Evidence that nothing updated the stack

• CloudTrail (EventSource=cloudformation.amazonaws.com) shows no call touching the Gen 2 auth nested stack between each CreateStackRefactor and its ExecuteStackRefactor.
• DescribeStackEvents on that stack: last event is the tool's own prepare update (UPDATE_COMPLETE, attempt 1); nothing after.
• No change sets left on either auth stack, no drift results, no stack policy on the nested stacks (the lock policy is on the Gen 1 root only), no termination protection.
• Other principals: none. The Gen 2 stack was deployed by a CI role; the refactor runs as an IAM user with AdministratorAccess.

Two smaller tool observations

1. After the failure, the holding stack stays in REVIEW_IN_PROGRESS with an empty template. On re-run, AuthCognitoForwardRefactorer.beforeMove/move throw Unexpected state of stack …-holding: REVIEW_IN_PROGRESS (the base ForwardCategoryRefactorer.beforeMove would have scheduled its deletion), and the automatic rollback dies in Cfn.fetchTemplate ("returned an empty template"). The stale holding stack has to be deleted by hand before any re-run or --rollback.
2. The plan phase leaves zero-change gen2-migration-<ts> change sets on the storage stacks on every run.

Questions

• Is ExecuteStackRefactor expected to refuse a nested stack that was updated directly by the tool's prepare step (so its template differs from what its parent last deployed)?
• Is a settle time required between CreateStackRefactor reaching CREATE_COMPLETE and ExecuteStackRefactor, or between the destination stack being created and execution?

Happy to share the refactor.operations snapshots or run diagnostics. Nothing has moved, Gen 1 is still locked and serving production, so we can retry on request.

[hide74]

I have same problem from yesterday. On 4th, Septemeber, I succeeded same operation without any problem.

[aaronjwhipple87]

@hide74 What all did you do to have it succeed? I have gone through every scenario.

[hide74]

@aaronjwhipple87 When I succeeded, I walked through all migration steps in the doc. But now I could not success it.

[aaronjwhipple87]

Follow-up, 2026-09-09 19:35 UTC — fourth reproduction, with the holding stack pre-created.

To rule out destination-stack creation as the trigger, we created the …-holding stack ourselves first (CREATE_COMPLETE, one AWS::CloudFormation::WaitConditionHandle placeholder, the same convention the tool uses for MigrationPlaceholder). The tool accepted it, and the resulting refactor contained only MOVE actions (5 × MOVE RESOURCE, no CREATE STACK). Result: identical refusal.

StackRefactorId 9b1d44b8-6da0-457f-a592-b97ba758ead2 — CREATE_COMPLETE / AVAILABLE
ExecuteStackRefactor → ValidationError: You cannot execute the refactor [...]. Stack [.../amplify-<appId>-gen2main-branch-<hash>-auth179371D7-12KDVELQQPKWH/fa794850-...] was updated since this refactor was created.

Run interactively, several minutes after the plan phase; CloudTrail still shows no call touching the source stack since the tool's own prepare update. So the refusal is independent of timing, human confirmation, and destination creation, and is tied to that source nested stack. The remaining candidate is that the source is a nested stack whose template was updated directly by the prepare step (so it differs from the template its parent last deployed). An AWS Support case is open in parallel (CloudFormation / APIs).

Small additional note: with a pre-created holding stack the automatic rollback fails with Unable to find forward mapping for resource amplifyAuthUserPool4BA7F805, because the mappings metadata only exists when the tool created the holding stack itself. Harmless here (nothing had moved), but worth knowing.

[aaronjwhipple87]

Root cause isolated (2026-09-09, us-west-2), reproducible without Amplify. Thirteen throwaway-stack variants (SNS topics only; parent → nested child; one topic refactored out to a new stack via create-stack-refactor --enable-stack-creation + execute-stack-refactor):

Variant	Child outputs	How the child's Outputs were changed	Result
standalone stack, no outputs	–	–	✅ executed
nested, no outputs, in sync with parent	–	–	✅ executed
nested, no outputs, updated directly (resource property)	–	–	✅ executed
nested, service role (CDK cfn-exec), no outputs	–	–	✅ executed
nested, output created as a literal ARN of the moved resource, parent consumes it, never changed	literal from creation	never	✅ executed
nested, output {Ref: T1} consumed by parent, then updated directly to the literal ARN (what gen2-migration refactor's prepare step does)	yes	direct update	❌ refused
same + service role	yes	direct update	❌ refused
same, then parent re-deployed the identical prepared template	yes	direct update	❌ refused
same, then parent re-deployed it with a tag change (real nested update through the parent)	yes	direct update	❌ refused
output changed only through the parent (never updated directly)	yes	parent-driven update	❌ refused
tainted, then two parent-driven output-section changes (add dummy output, restore exact)	yes	both	❌ refused
tainted, then the parent stops consuming the output	yes	direct update	❌ refused

Every refusal is the same ValidationError: You cannot execute the refactor [...]. Stack [<child>] was updated since this refactor was created, while describe-stack-refactor keeps saying CREATE_COMPLETE / AVAILABLE, and CloudTrail shows no call touching the child between create and execute. The outputs' values never changed in any variant, only their definitions (Ref → literal). Drift was ruled out (all stacks IN_SYNC before the real attempts).

Observed rule: a nested stack whose Outputs section has changed since the stack was created cannot be a stack-refactor source, and nothing done afterwards (parent redeploy, removing the parent's dependency) clears it. The tool's prepare step must rewrite those outputs (they Ref the very resources being moved), so refactor is currently blocked for any auth/storage category. On our real app it failed identically five times (refactor ids 5e6808f4…, 8538d884…, 1dfcaec1…, 9b1d44b8…, bf127438…).

An AWS Support case (CloudFormation / APIs) is open with the full reproduction; happy to share the case id with the Amplify team privately. Until CloudFormation answers, the only ways forward we see are (a) waiting for a fix/explanation, or (b) not refactoring: retain + delete the Gen 1 stacks and referenceAuth() / a referenced bucket in Gen 2.

[aaronjwhipple87]

AWS Support confirmation (2026-09-10). Support Engineering reviewed the reproduction above and replied that they "see other cases reported with similar errors recently" and that "this appears to be a CloudFormation service-side issue"; it has been escalated to the internal CloudFormation team. No ETA yet. For the Amplify maintainers: the gen2-migration refactor step is blocked for everyone until that is resolved, because CloudFormation currently refuses ExecuteStackRefactor on any nested source stack whose Outputs section changed after creation, and the tool's prepare step must make exactly that change. Happy to share the support case reference with the team privately.

[hide74]

@aaronjwhipple87 Thanks a lot for this information.

[aaronjwhipple87]

Update from AWS Support (2026-09-11): the internal CloudFormation team has "identified a service-side issue that is impacting your ability to execute stack refactors" and is "actively working on a fix, with an estimated resolution date of September 25, 2026."

Interim workaround they offered (manual, "intricate", at your own risk — we are not taking it for production auth/storage): (1) UpdateStack the source stack to set DeletionPolicy: Retain on the resources to move; (2) UpdateStack the source again removing those resources from the template (resources stay intact); (3) UpdateStack the destination stack adding the resources to its template, relying on CloudFormation resource auto-import.

For maintainers: until the fix ships, amplify gen2-migration refactor cannot execute against any auth/storage category (its prepare step rewrites the nested stack's Outputs, which is the trigger). Worth a note in the guide, and worth re-testing the e2e refactor flow after Sept 25. AWS suggested we also open a case with the Amplify team; happy to share the CloudFormation case id privately.

[aaronjwhipple87]

Per AWS Support's suggestion we have also opened an Amplify Framework / CLI support case, id 178914507800209 (2026-09-11), asking the Amplify team to (1) confirm awareness and plan an end-to-end re-test of gen2-migration refactor once the CloudFormation fix ships (est. 2026-09-25), (2) add an interim note to the migration guide, and (3) look at two smaller tool issues we hit on the way: a stale -holding stack left in REVIEW_IN_PROGRESS after a failed run is rejected by the auth refactorer on re-run (and the automatic rollback fails on its empty template), so it has to be deleted by hand; and the plan phase leaves zero-change gen2-migration-* change sets on stacks whose prepare step is later skipped. We also suggested a DetectStackDrift pre-flight on every nested stack involved — drift on two of ours would otherwise have surfaced mid-refactor. Maintainers: feel free to reference either case (CloudFormation 178897886700512, Amplify 178914507800209).

[aaronjwhipple87]

Update 2026-09-21: resolved. AWS deployed the CloudFormation fix to us-west-2 ahead of the Sept 25 estimate (confirmed on Amplify case 178914507800209 on 2026-09-18).

• Our isolated repro (a nested stack whose Outputs section changed after creation) now executes: refactor a100089f → EXECUTE_COMPLETE.
• amplify gen2-migration refactor then completed end to end on utahgrown/dev, unchanged: four stack refactors, Cognito user pool + both app clients + identity pool + S3 bucket moved into the Gen 2 branch stacks with unchanged physical ids. Stacks already in the changed-Outputs state are covered; no extra stack update was needed first.
• Step 8 (postRefactor() deploy) completed the same day with no resource replacement.

Three things worth knowing before your Step 8 deploy:

1. Pin the adopted Cognito names. The generated auth/resource.ts omits UserPoolName / IdentityPoolName. After the refactor the adopted Gen 1 pool carries explicit names, and UserPoolName is a replacement-class property, so the reconcile deploy would try to replace the pool. Set both in postRefactor() the same way the generator pins the storage bucketName:

   const cfn = backend.auth.resources.cfnResources;
   cfn.cfnUserPool.userPoolName = '<live pool name>';
   cfn.cfnIdentityPool.identityPoolName = '<live identity pool name>';

2. An existing bucket policy on the adopted bucket blocks Step 8. AWS::S3::BucketPolicy.Bucket requires replacement, so CloudFormation tries to create a policy on the adopted bucket and refuses with The bucket policy already exists on bucket … (clean rollback). Port the statements into backend.ts, save the live policy, aws s3api delete-bucket-policy immediately before triggering the deploy.
3. Diff a local synth against the live nested templates first. This works without deploying:

   AWS_BRANCH=<branch> CI=1 npx cdk synth --app "npx tsx amplify/backend.ts" \
     --context amplify-backend-namespace=<appId> --context amplify-backend-name=<branch> \
     --context amplify-backend-type=branch --output ./cdk.out --quiet --no-lookups
   

   Compare cdk.out/*auth*.nested.template.json / *storage*.nested.template.json with aws cloudformation get-template of the live stacks; nothing replacement-class (UserPoolName, UsernameAttributes, UsernameConfiguration, Schema, GenerateSecret, IdentityPoolId, BucketName) should differ. Also note the Gen 2 storage stack's Custom::S3AutoDeleteObjects re-points to the adopted production bucket; keep the generated Retain override on it.

Support cases 178897886700512 (CloudFormation) and 178914507800209 (Amplify) have the full details; the two tool defects reported earlier (stale REVIEW_IN_PROGRESS holding stack on re-run; zero-change change sets from the plan phase) are with the Amplify team.

[aaronjwhipple87]

At the Amplify support team's request the two tool defects from this thread (stale REVIEW_IN_PROGRESS holding stack blocking re-runs and breaking the automatic rollback; zero-change change sets left by the plan phase) plus the DetectStackDrift pre-flight suggestion are now tracked in a dedicated issue: #14988.