# Syncing stacks with source code stored in a Git repository with Git sync With Git sync, you can manage your CloudFormation stacks with source control. You do this by configuring CloudFormation to monitor a Git repository. The repository is monitored for changes to two files: + A CloudFormation template file that defines a stack + A stack deployment file that contains parameters that configure the stack With Git sync, you can use pull requests and version tracking to configure, deploy, and update your CloudFormation stacks from a centralized location. When you commit changes to the template or the deployment file, CloudFormation automatically updates the stack. If you use pull requests, CloudFormation can leave a comment on the pull request explaining what changes will be made to your stack before actually updating it. However, you need to enable this feature first. Git sync provides a console interface that you can use to link to a repository, generate a stack deployment file, update a CloudFormation template, and submit a pull request to your repository. Git sync also provides a status dashboard that you can use to monitor, edit, and troubleshoot active Git sync stack deployments. Git sync is accessed through the [CloudFormation console](https://console.aws.amazon.com/cloudformation/) when you [create a stack](cfn-console-create-stack.md). You can also access Git sync using CodeConnections. For more information, see [Working with sync configurations for linked repositories](https://docs.aws.amazon.com/dtconsole/latest/userguide/configurations.html) in the *Developer Tools Console User Guide*. Git sync supports [GitHub](https://github.com/), [GitHub Enterprise](https://github.com/enterprise), [GitLab](https://about.gitlab.com/), [Bitbucket](https://bitbucket.org), and [GitLab self-managed](https://docs.gitlab.com/subscriptions/self_managed/) repositories. **Note** Git sync is available in the following regions: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), Europe (Frankfurt), Europe (Milan), and South America (São Paulo). For information about using Git sync with a multi-account strategy, see the following blog post [Use CloudFormation Git sync to configure resources in customer accounts](https://aws.amazon.com/blogs/devops/use-aws-cloudformation-git-sync-to-configure-resources-in-customer-accounts/). **Topics** + [How Git sync works](git-sync-concepts-terms.md) + [Prerequisites](git-sync-prereq.md) + [Create a stack from repository source code](git-sync-create-stack-from-repository-source-code.md) + [Enable comments on pull requests](gitsync-enable-comments-on-pull-requests.md) + [Status dashboard](git-sync-status.md) # How Git sync works with CloudFormation This topic describes how Git sync works and introduces the key concepts required to work with it. **Topics** + [ ## How Git sync works ](#git-sync-concepts-terms-how) + [ ## Comments on pull requests ](#git-sync-comments-on-pull-requests) + [ ## Stack deployment file ](#git-sync-concepts-terms-depoyment-file) + [ ## CloudFormation template file ](#git-sync-concepts-terms-template-file) + [ ## Template definition repository ](#git-sync-concepts-terms-template-definition-repository) ## How Git sync works To use Git sync, you first must connect a Git provider to CloudFormation using the [CodeConnections](https://docs.aws.amazon.com/codeconnections/latest/APIReference/Welcome.html) service. In the procedures in this guide, the connection is created through the CodeConnections console. Alternatively, you can create the connection with the AWS CLI. You can use any of the following Git providers: + [GitHub](https://github.com/) + [GitHub Enterprise](https://github.com/enterprise/) + [GitLab](https://about.gitlab.com/) + [Bitbucket](https://bitbucket.org) + [GitLab self-managed](https://docs.gitlab.com/subscriptions/self_managed/) Next, you create a CloudFormation template that defines your stack and add it to your repository. This template file is monitored. CloudFormation updates the stack automatically when changes are committed to it. In the CloudFormation console, you create a new stack and choose **Sync from Git** to tell CloudFormation to use Git sync. You'll specify the repository and branch you want CloudFormation to monitor, and specify the CloudFormation template in your repository that defines the stack. During configuration, you can either provide your own stack deployment file from your repository, or have Git sync generate one for you. The stack deployment file contains parameters and values that configure the resources in your stack. This stack deployment file is monitored. CloudFormation updates the stack automatically when changes are committed to it. Git sync creates a pull request in your repository to sync your stack with the CloudFormation template file and stack deployment file. If Git sync generates the stack deployment file for you, it's submitted to your repository by Git sync. You then merge the pull request to your repository so that CloudFormation provisions the stack, configures it with your deployment parameters, and begins monitoring your repository for changes. From then on, whenever you make changes to your template file or stack deployment file and commit them to your repository, CloudFormation will automatically detect the changes. If your team uses pull requests, your team members can then review and approve the changes before they're deployed. Once the pull request is accepted, CloudFormation deploys your changes. You can monitor the status of your Git sync configuration for the stack and see a history of commits applied to the stack in the CloudFormation console. The console also provides tools for reconfiguring Git sync and troubleshooting issues. ## Comments on pull requests You can choose to have CloudFormation create a summary of the code changes in pull requests through the CodeConnections service by turning on the **Enable comment on pull request** option in the console. Providing a summary of the changes in pull requests means that team members can easily review and understand the impact of the proposed modifications before merging the pull request. For more information, see [Enable CloudFormation to post a summary of stack changes in pull requests](gitsync-enable-comments-on-pull-requests.md). ## Stack deployment file A stack deployment file is a JavaScript Object Notation (JSON) or YAML standard formatted file that contains parameters and values that manage your CloudFormation stack. It is monitored for changes. When changes to the file are committed to the repository, the associated stack is automatically updated. The stack deployment file contains a key-value pair and two dictionaries: + `template-file-path` This is the full repository path for the CloudFormation template file. The template file declares the resources for the CloudFormation stack associated with this deployment file. + `parameters` The parameters dictionary contains key-value pairs that configure the resources in the stack. A stack deployment file can have up to 50 parameters. + `tags` The tags dictionary contains optional key-value pairs that you can use to identify and categorize resources in the stack. A stack deployment file can have up to 50 tags. You can provide your own stack deployment file, or have Git sync create one for you and automatically submit a pull request to your repository. You can manage the parameters and tags by editing the stack deployment file and committing changes to the repository. The following is an example of a Git sync stack deployment file: ``` template-file-path: fargate-srvc/my-stack-template.yaml parameters: image: public.ecr.aws/lts/nginx:latest task_size: x-small max_capacity: 5 port: 8080 env: production tags: cost-center: '123456' org: 'AWS' ``` ## CloudFormation template file A template file contains a declaration of the AWS resources that make up a CloudFormation stack. With Git sync, the template file is stored in your Git repository and referenced by the stack deployment file. You can manage the stack by editing the template file and committing changes to the repository. For more information, see [Working with CloudFormation templates](template-guide.md). ## Template definition repository The template definition repository is the Git repository that is linked to CloudFormation through Git sync. The repository is monitored for changes to the CloudFormation template and stack deployment file. When you commit changes to the file, the associated stack is updated automatically. **Important** When you configure the template definition repository in the Git sync console, select the correct *repository* and *branch* from the Git connection. Git sync only monitors the configured repository and branch for changes to the CloudFormation template and the stack deployment file. # Prerequisites for syncing stacks to a Git repository using Git sync Before you sync a CloudFormation stack to your Git repository, verify that the following requirements are met. **Topics** + [ ## Git repository ](#git-sync-prereq-repo) + [ ## CloudFormation template ](#git-sync-prereq-template) + [ ## Git sync service role ](#git-sync-prereq-iam) + [ ## IAM permissions for console users ](#git-sync-prereq-user-permissions) ## Git repository You must have a Git repository hosted on one of the following platforms. + [GitHub](https://github.com/) + [GitHub Enterprise](https://github.com/enterprise) + [GitLab](https://about.gitlab.com/) + [Bitbucket](https://bitbucket.org) + [GitLab self-managed](https://docs.gitlab.com/subscriptions/self_managed/) The repository can be either public or private. You will need to connect this Git repository to CloudFormation though the [Connections console](https://console.aws.amazon.com/codesuite/settings/connections). ## CloudFormation template Your Git repository must contain a [CloudFormation template file](git-sync-concepts-terms.md#git-sync-concepts-terms-template-file) checked into the branch you intend to connect with Git sync. This template will be referenced by the [stack deployment file](git-sync-concepts-terms.md#git-sync-concepts-terms-depoyment-file). ## Git sync service role Git sync requires an IAM role. You can choose to have an IAM role created for your stack when you configure Git sync, or you can use an existing role. **Note** An automatically generated IAM role only applies permissions to the stack for which the role is generated. To reuse an automatically generated IAM role, you must edit the role for the new stack. ### Required permissions for Git sync service role The IAM role that you provide for Git sync requires the following permissions. + `cloudformation:CreateChangeSet` + `cloudformation:DeleteChangeSet` + `cloudformation:DescribeChangeSet` + `cloudformation:DescribeStackEvents` + `cloudformation:DescribeStacks` + `cloudformation:ExecuteChangeSet` + `cloudformation:ListChangeSets` + `cloudformation:ValidateTemplate` + `events:PutRule` + `events:PutTargets` **Note** The preceding required permissions are automatically added to IAM roles that Git sync generates. The following example IAM role includes the prerequisite permissions for Git sync. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "SyncToCloudFormation", "Effect": "Allow", "Action": [ "cloudformation:CreateChangeSet", "cloudformation:DeleteChangeSet", "cloudformation:DescribeChangeSet", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStacks", "cloudformation:ExecuteChangeSet", "cloudformation:GetTemplate", "cloudformation:ListChangeSets", "cloudformation:ListStacks", "cloudformation:ValidateTemplate" ], "Resource": "*" }, { "Sid": "PolicyForManagedRules", "Effect": "Allow", "Action": [ "events:PutRule", "events:PutTargets" ], "Resource": "*", "Condition": { "StringEquals": { "events:ManagedBy": ["cloudformation.sync.codeconnections.amazonaws.com"] } } }, { "Sid": "PolicyForDescribingRule", "Effect": "Allow", "Action": "events:DescribeRule", "Resource": "*" } ] } ``` ------ #### Trust policy You must provide the following trust policy when you create the role to define the trust relationship. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CfnGitSyncTrustPolicy", "Effect": "Allow", "Principal": { "Service": "cloudformation.sync.codeconnections.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ We recommend that you use the `aws:SourceArn` and `aws:SourceAccount` condition keys to protect yourself against the confused deputy problem. The source account is your account ID and the source ARN is the ARN of the connection in the [CodeConnections](https://docs.aws.amazon.com/codeconnections/latest/APIReference/Welcome.html) service that allows CloudFormation to connect to your Git repository. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CfnGitSyncTrustPolicy", "Effect": "Allow", "Principal": { "Service": "cloudformation.sync.codeconnections.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:codeconnections:us-east-1:123456789012:connection/EXAMPLE64-8aad-4d5d-8878-dfcab0bc441f" } } } ] } ``` ------ For more information about the confused deputy problem, see [Cross-service confused deputy prevention](cross-service-confused-deputy-prevention.md). ## IAM permissions for console users To successfully set up Git sync through the CloudFormation console, end users must also be granted permissions through IAM. The following `codeconnections` permissions are required to create and manage the connection to your Git repository. + `codeconnections:CreateRepositoryLink` + `codeconnections:CreateSyncConfiguration` + `codeconnections:DeleteRepositoryLink` + `codeconnections:DeleteSyncConfiguration` + `codeconnections:GetRepositoryLink` + `codeconnections:GetSyncConfiguration` + `codeconnections:ListRepositoryLinks` + `codeconnections:ListSyncConfigurations` + `codeconnections:ListTagsForResource` + `codeconnections:TagResource` + `codeconnections:UntagResource` + `codeconnections:UpdateRepositoryLink` + `codeconnections:UpdateSyncBlocker` + `codeconnections:UpdateSyncConfiguration` + `codeconnections:UseConnection` Console users must also have the following `cloudformation` permissions to view and manage stacks during the Git sync setup process. + `cloudformation:CreateChangeSet` + `cloudformation:DeleteChangeSet` + `cloudformation:DescribeChangeSet` + `cloudformation:DescribeStackEvents` + `cloudformation:DescribeStacks` + `cloudformation:ExecuteChangeSet` + `cloudformation:GetTemplate` + `cloudformation:ListChangeSets` + `cloudformation:ListStacks` + `cloudformation:ValidateTemplate` **Note** While change set permissions (`cloudformation:CreateChangeSet`, `cloudformation:DeleteChangeSet`, `cloudformation:DescribeChangeSet`, `cloudformation:ExecuteChangeSet`) might not be strictly required for console-only usage, they're recommended to enable full stack inspection and management capabilities. The following example IAM policy includes the user permissions needed to set up Git sync through the console. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "CodeConnectionsPermissions", "Effect": "Allow", "Action": [ "codeconnections:CreateRepositoryLink", "codeconnections:CreateSyncConfiguration", "codeconnections:DeleteRepositoryLink", "codeconnections:DeleteSyncConfiguration", "codeconnections:GetRepositoryLink", "codeconnections:GetSyncConfiguration", "codeconnections:ListRepositoryLinks", "codeconnections:ListSyncConfigurations", "codeconnections:ListTagsForResource", "codeconnections:TagResource", "codeconnections:UntagResource", "codeconnections:UpdateRepositoryLink", "codeconnections:UpdateSyncBlocker", "codeconnections:UpdateSyncConfiguration", "codeconnections:UseConnection", "codeconnections:CreateForcedTargetSync", "codeconnections:CreatePullRequestForResource" ], "Resource": "*" }, { "Sid": "CloudFormationConsolePermissions", "Effect": "Allow", "Action": [ "cloudformation:CreateChangeSet", "cloudformation:DeleteChangeSet", "cloudformation:DescribeChangeSet", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStacks", "cloudformation:ExecuteChangeSet", "cloudformation:GetTemplate", "cloudformation:ListChangeSets", "cloudformation:ListStacks", "cloudformation:ValidateTemplate" ], "Resource": "*" } ] } ``` ------ **Note** When creating an IAM policy that includes the permissions `codeconnections:CreateForcedTargetSync` and `codeconnections:CreatePullRequestForResource`, you might see a warning in the IAM console stating that these actions do not exist. This warning can be ignored, and the policy will still be created successfully. These permissions are required for certain Git sync operations despite not being recognized by the IAM console. # Create a stack from repository source code with Git sync This topic explains how to create a CloudFormation stack that syncs to a Git repository with Git sync. **Important** Before you continue, complete all [prerequisites](git-sync-prereq.md) in the previous section. ## Create a stack from repository source code 1. Sign in to the AWS Management Console and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. On the navigation bar at the top of the screen, choose the AWS Region to create the stack in. 1. On the **Stacks** page, choose **Create stack**, and then choose **With new resources (standard)**. 1. On the **Create stack** page, do the following: 1. For **Prerequisite - Prepare template**, keep **Choose an existing template** selected. 1. For **Specify template**, choose **Sync from Git**, and then choose **Next**. 1. On the **Specify stack details** page, for **Stack name**, type a name for your stack. Stack names can include letters (A-Z and a-z), numbers (0-9), and dashes (-). 1. For **Stack deployment file**, **Deployment file creation**: + If you *haven't* created a stack deployment file and added it to your repository, choose **Create the file using the following parameters and place it in my repository.** + If you have a stack deployment file in your repository, choose **I am providing my own file in my repository.** 1. For **Template definition repository**, choose **Choose a linked Git repository** to choose a Git repository that's already linked to CloudFormation, or **Link a Git repository** to link a new one. If you choose **Link a Git repository**, do the following: 1. For **Select repository provider**, choose one of the following: + **GitHub** + **GitHub Enterprise Server** + **GitLab** + **Bitbucket** + **GitLab self-managed** 1. For **Connection**, choose a connection from the list. If no options appear in the **Connection** list, choose **add a new connection** to go to the [Connections console](https://console.aws.amazon.com/codesuite/settings/connections) and create a connection to your repository. 1. In the **Repository** list, select the Git repository that contains your stack template file. 1. In the **Branch** list, select the branch you'd like Git sync to monitor. **Note** Git sync only monitors the selected branch for changes to the CloudFormation template and stack deployment files. Any changes you'd like to apply to your stack must be committed to this branch. 1. For the **Deployment file path**, specify the full path including the stack deployment file name from the root of your repository branch. If CloudFormation is generating the file for you, this is where the file will be committed in your repository. If you are providing the file, this is the location of the file in your repository. 1. Add an **IAM role**. The IAM role includes permissions that are required for CloudFormation to sync the stack from your Git repository. You can choose **New IAM role** to generate a new role, or choose **Existing IAM role** to select an existing role from your AWS account. If you choose to generate a new role, the required permissions are included in the role. 1. Enable or turn off comments on pull request: + To have CloudFormation post change set information in pull requests for stack updates, keep the **Enable comment on pull request** toggle switched on. + If you switch this toggle off, CloudFormation won't describe the differences between the current stack configuration and the proposed changes in pull requests when the repo files are updated. 1. For the **Template file path**, specify the full path from the root of your repository for the stack template file. 1. (Optional) To specify the stack parameters, choose **Add parameter**, provide a key and value for each parameter, and then choose **Next**. For more information, see [Stack deployment file](git-sync-concepts-terms.md#git-sync-concepts-terms-depoyment-file). For example, to specify a **port=8080** parameter in your stack deployment file, do the following: 1. Choose **Add parameter**. 1. For **Key**, enter **port**. 1. For **Value**, enter **8080**. 1. (Optional) To specify stack tags, choose **Add new tag**, provide a tag key and value for each tag, and then choose **Next**. For more information, see [Stack deployment file](git-sync-concepts-terms.md#git-sync-concepts-terms-depoyment-file). 1. Choose **Next** to continue to **Configure stack options**. For information about configuring stack options, see [Configure stack options](cfn-console-create-stack.md#configure-stack-options). When you've completed your stack configuration, choose **Next** to continue. 1. Review your stack settings and confirm the following: + The stack template is configured correctly and set to **Sync from Git**. + The deployment file is configured correctly. + The template definition repository is configured correctly, in particular, that the correct **Repository** and **Branch name** are selected. + The preview of the deployment file is correct and contains the expected parameters and values. 1. Choose **Submit** to create the stack. After you choose **Submit**, a pull request is automatically created in your Git repository. You must merge this pull request into your Git repository to create your stack. After the stack is created, CloudFormation monitors your Git repository for changes. ## Update your stack from your Git repository To update the stack, make changes directly to your template file or stack deployment file in your Git repository. After you commit your changes to the monitored branch, CloudFormation automatically updates the stack. If you use pull requests, a pull request is automatically created in your Git repository before the stack is updated. You must merge this pull request into your Git repository to update your stack. In the CloudFormation console, you can select the stack and choose the **Git sync** tab to view information about the status of the stack and sync events. For more information, see [Git sync status dashboard](git-sync-status.md). # Enable CloudFormation to post a summary of stack changes in pull requests This topic shows you how to enable CloudFormation to post a summary of stack changes in pull requests in your Git repository. By enabling the comments on pull requests feature, you allow CloudFormation to post a comment that describes the differences between the current stack configuration and the proposed changes when the repo files are updated. This comment provides a summary of the resources that will be added, modified, or deleted, allowing you to perform a thorough code review before merging the pull request. **To enable comments on pull requests for a new stack (console)** When you create the stack, on the **Specify stack details** page, under **Template definition repository**, make sure the **Enable comment on pull request** toggle is switched on. This is the default setting for new stacks. **To enable comments on pull requests for an existing stack (console)** 1. Sign in to the AWS Management Console and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/). 1. On the navigation bar at the top of the screen, choose the AWS Region that you created your stack in. 1. On the **Stacks** page, choose the running stack that you want to update. 1. Choose the **Git sync** tab, and then choose **Edit**. 1. On the **Edit Git sync settings** page, under **Template definition repository**, switch the **Enable comment on pull request** toggle on. 1. Choose **Update configuration**. # Git sync status dashboard To view the status of a AWS CloudFormation Git sync deployment, select the stack in the CloudFormation console and choose the **Git sync** tab. The Git sync tab is divided into two panels, **Git sync status** and **Latest sync events**. ## Git sync status The top panel provides the following information about the Git sync configuration for the stack. ****Repository**** A link to the repository that is connected to Git sync ****Repository provider**** The name of the repository provider ****Branch**** The name of the branch that Git sync is monitoring ****Deployment file path**** The full path to the stack deployment file for this stack ****Repository sync status**** The status of the most recent sync operation ****Repository sync status message**** The message of the most recent sync operation ****Git sync status**** The status of Git sync for this stack ****Provisioning status**** The status of the provisioning operation In the upper-right of the panel, use the following buttons to modify or update Git sync: + **Edit** - Edit the Git sync configuration. + **Retry latest commit** - Update the stack according to the most recent commit to the repository. + **Disconnect** - Disconnect Git sync from the stack. + **Refresh** - Refresh the Git sync status panel. ## Latest sync events The **Latest sync events** panel displays a table of commits that have been applied to the stack. You can sort the table using the arrows in the header of each column. The table can be sorted in ascending or descending order according to the following: + **Date** + **Commit ID** + **Event** + **Date** + **Event Type** ## Supported stack states Git sync can only be configured for a stack if the stack is in one of the following supported states: + `CREATE_COMPLETE` + `UPDATE_COMPLETE` + `UPDATE_ROLLBACK_COMPLETE` + `IMPORT_COMPLETE` + `IMPORT_ROLLBACK_COMPLETE` The following table contains a complete list of stack status codes with descriptions: | Stack status and optional detailed status | Description | | --- | --- | | `CREATE_COMPLETE` | Successful creation of one or more stacks. | | `CREATE_IN_PROGRESS` | Ongoing creation of one or more stacks. | | `CREATE_FAILED` | Unsuccessful creation of one or more stacks. View the stack events to see any associated error messages. Possible reasons for a failed creation include insufficient permissions to work with all resources in the stack, parameter values rejected by an AWS service, or a timeout during resource creation. | | `DELETE_COMPLETE` | Successful deletion of one or more stacks. Deleted stacks are retained and viewable for 90 days. | | `DELETE_FAILED` | Unsuccessful deletion of one or more stacks. Because the delete failed, you might have some resources that are still running; however, you can't work with or update the stack. Delete the stack again or view the stack events to see any associated error messages. | | `DELETE_IN_PROGRESS` | Ongoing removal of one or more stacks. | | `REVIEW_IN_PROGRESS` | Ongoing creation of one or more stacks with an expected StackId but without any templates or resources. A stack with this status code counts against the [maximum possible number of stacks](cloudformation-limits.md). | | `ROLLBACK_COMPLETE` | Successful removal of one or more stacks after a failed stack creation or after an explicitly canceled stack creation. The stack returns to the previous working state. Any resources that were created during the create stack operation are deleted. This status exists only after a failed stack creation. It signifies that all operations from the partially created stack have been appropriately cleaned up. When in this state, only a delete operation can be performed. | | `ROLLBACK_FAILED` | Unsuccessful removal of one or more stacks after a failed stack creation or after an explicitly canceled stack creation. Delete the stack or view the stack events to see any associated error messages. | | `ROLLBACK_IN_PROGRESS` | Ongoing removal of one or more stacks after a failed stack creation or after an explicitly canceled stack creation. | | `UPDATE_COMPLETE` | Successful update of one or more stacks. | | `UPDATE_COMPLETE_CLEANUP_IN_PROGRESS` | Ongoing removal of old resources for one or more stacks after a successful stack update. For stack updates that require resources to be replaced, CloudFormation creates the new resources first and then deletes the old resources to help reduce any interruptions with your stack. In this state, the stack has been updated and is usable, but CloudFormation is still deleting the old resources. | | `UPDATE_FAILED` | Unsuccessful update of one or more stacks. View the stack events to see any associated error messages. | | `UPDATE_IN_PROGRESS` | Ongoing update of one or more stacks. | | `UPDATE_ROLLBACK_COMPLETE` | Successful return of one or more stacks to a previous working state after a failed stack update. | | `UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS` | Ongoing removal of new resources for one or more stacks after a failed stack update. In this state, the stack has been rolled back to its previous working state and is usable, but CloudFormation is still deleting any new resources it created during the stack update. | | `UPDATE_ROLLBACK_FAILED` | Unsuccessful return of one or more stacks to a previous working state after a failed stack update. When in this state, you can delete the stack or [continue rollback](using-cfn-updating-stacks-continueupdaterollback.md). You might need to fix errors before your stack can return to a working state. Or, you can contact Support to restore the stack to a usable state. | | `UPDATE_ROLLBACK_IN_PROGRESS` | Ongoing return of one or more stacks to the previous working state after failed stack update. | | `IMPORT_IN_PROGRESS` | The import operation is currently in progress. | | `IMPORT_COMPLETE` | The import operation successfully completed for all resources in the stack that support `resource import`. | | `IMPORT_ROLLBACK_IN_PROGRESS` | Import will roll back to the previous template configuration. | | `IMPORT_ROLLBACK_FAILED` | The import rollback operation failed for at least one resource in the stack. Results will be available for the resources CloudFormation successfully imported. | | `IMPORT_ROLLBACK_COMPLETE` | Import successfully rolled back to the previous template configuration. |