# スタックの進行状況を監視する
このセクションでは、現在進行中のスタックデプロイを監視する方法について説明します。CloudFormation は、デプロイイベントの詳細な時系列リストを提供します。これには、デプロイの進捗状況と、デプロイ中に発生した問題が表示されます。
**Topics**
+ [スタックイベントを表示する](view-stack-events.md)
+ [オペレーション別にスタックイベントを表示する](view-stack-events-by-operation.md)
+ [スタックデプロイタイムライングラフを表示する](stack-deployment-timeline-graph.md)
+ [スタック作成イベントを理解する](stack-resource-configuration-complete.md)
+ [スタック更新を監視する](using-cfn-updating-stacks-monitor-stack.md)
+ [
# 更新のロールバックを続ける
](using-cfn-updating-stacks-continueupdaterollback.md)
+ [
# スタックが失敗する原因を判断する
](determine-root-cause-for-stack-failures.md)
+ [スタック障害オプション](stack-failure-options.md)
# CloudFormation スタックイベントを表示する
スタックイベントを表示して、スタックとそのリソースの進行状況とステータスをモニタリングできます。スタックイベントは、リソースがいつ作成、更新、削除されるか、およびスタックデプロイが想定どおりに進行しているかどうかを理解するのに役立ちます。
**Topics**
+ [
## スタックイベントを表示する (コンソール）
](#view-stack-events-console)
+ [
## スタックイベントを表示する (AWS CLI）
](#view-stack-events-cli)
+ [
## スタックステータスコード
](#cfn-console-view-stack-data-resources-status-codes)
## スタックイベントを表示する (コンソール）
**スタックイベントを表示する**
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 画面の上部のナビゲーションバーで、スタックを作成した AWS リージョンを選択します。
1. CloudFormation コンソールの **[Stacks]** (スタック) ページで、スタック名を選択します。CloudFormation は選択したスタックのスタック詳細を表示します。
1. **[イベント]** タブを選択して、スタックのために CloudFormation が生成したスタックイベントを表示します。
CloudFormation は、スタックイベントを 1 分ごとに自動的に更新します。これに加えて、CloudFormation は新しいスタックイベントの発生時に **[新しいイベントを利用できます]** バッジを表示します。更新アイコンを選択して、これらのイベントをリストにロードします。スタックの作成イベントを表示することで、スタックの作成 (または失敗、スタックをデバッグしている場合) につながる一連のイベントを理解することができます。
スタックの作成中、スタックは **[スタック]** ページでステータスが `CREATE_IN_PROGRESS` と表示されます。スタックが正常に作成されると、ステータスが `CREATE_COMPLETE` に変わります。
詳細については、「[CloudFormation スタック作成イベントを理解する](stack-resource-configuration-complete.md)」および「[スタック更新の進行状況を監視する](using-cfn-updating-stacks-monitor-stack.md)」を参照してください。
## スタックイベントを表示する (AWS CLI）
代替手段として、スタックが作成されている間に [describe-stack-events](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/describe-stack-events.html) コマンドを使用し、報告されるイベントを表示することができます。
以下の **describe-stack-events** コマンドは、`my-stack` スタックイベントを記述します。
```
aws cloudformation describe-stack-events --stack-name my-stack
```
以下に、応答の例を示します。
```
{
"StackEvents": [
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "7b755820-7edf-11f0-ab15-0673b09f3847",
"StackName": "my-stack",
"LogicalResourceId": "my-stack",
"PhysicalResourceId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"ResourceType": "AWS::CloudFormation::Stack",
"Timestamp": "2025-08-21T22:37:56.243000+00:00",
"ResourceStatus": "CREATE_COMPLETE",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "WebServer-CREATE_COMPLETE-2025-08-21T22:37:54.356Z",
"StackName": "my-stack",
"LogicalResourceId": "WebServer",
"PhysicalResourceId": "i-099df76cb31b866a9",
"ResourceType": "AWS::EC2::Instance",
"Timestamp": "2025-08-21T22:37:54.356000+00:00",
"ResourceStatus": "CREATE_COMPLETE",
"ResourceProperties": "{\"UserData\":\"IyEvYmluL2Jhc2gKeXVtIGluc3RhbGwgLXkgYXdzLWNmbi1ib290c3RyYXAKL29wdC9hd3MvYmluL2Nmbi1pbml0IC12IC0tc3RhY2sgc2Rmc2RhZnNhZHNka2wgLS1yZXNvdXJjZSBXZWJTZXJ2ZXIgLS1yZWdpb24gdXMtd2VzdC0yCg==\",\"ImageId\":\"ami-0bbc328167dee8f3c\",\"InstanceType\":\"t2.micro\",\"SecurityGroupIds\":[\"my-stack-WebServerSecurityGroup-n8A43bQT1ty2\"],\"Tags\":[{\"Value\":\"Bootstrap Tutorial Web Server\",\"Key\":\"Name\"}]}",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "WebServer-CREATE_IN_PROGRESS-2025-08-21T22:37:31.226Z",
"StackName": "my-stack",
"LogicalResourceId": "WebServer",
"PhysicalResourceId": "i-099df76cb31b866a9",
"ResourceType": "AWS::EC2::Instance",
"Timestamp": "2025-08-21T22:37:31.226000+00:00",
"ResourceStatus": "CREATE_IN_PROGRESS",
"ResourceStatusReason": "Resource creation Initiated",
"ResourceProperties": "{\"UserData\":\"IyEvYmluL2Jhc2gKeXVtIGluc3RhbGwgLXkgYXdzLWNmbi1ib290c3RyYXAKL29wdC9hd3MvYmluL2Nmbi1pbml0IC12IC0tc3RhY2sgc2Rmc2RhZnNhZHNka2wgLS1yZXNvdXJjZSBXZWJTZXJ2ZXIgLS1yZWdpb24gdXMtd2VzdC0yCg==\",\"ImageId\":\"ami-0bbc328167dee8f3c\",\"InstanceType\":\"t2.micro\",\"SecurityGroupIds\":[\"my-stack-WebServerSecurityGroup-n8A43bQT1ty2\"],\"Tags\":[{\"Value\":\"Bootstrap Tutorial Web Server\",\"Key\":\"Name\"}]}",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "WebServer-CREATE_IN_PROGRESS-2025-08-21T22:37:29.210Z",
"StackName": "my-stack",
"LogicalResourceId": "WebServer",
"PhysicalResourceId": "",
"ResourceType": "AWS::EC2::Instance",
"Timestamp": "2025-08-21T22:37:29.210000+00:00",
"ResourceStatus": "CREATE_IN_PROGRESS",
"ResourceProperties": "{\"UserData\":\"IyEvYmluL2Jhc2gKeXVtIGluc3RhbGwgLXkgYXdzLWNmbi1ib290c3RyYXAKL29wdC9hd3MvYmluL2Nmbi1pbml0IC12IC0tc3RhY2sgc2Rmc2RhZnNhZHNka2wgLS1yZXNvdXJjZSBXZWJTZXJ2ZXIgLS1yZWdpb24gdXMtd2VzdC0yCg==\",\"ImageId\":\"ami-0bbc328167dee8f3c\",\"InstanceType\":\"t2.micro\",\"SecurityGroupIds\":[\"my-stack-WebServerSecurityGroup-n8A43bQT1ty2\"],\"Tags\":[{\"Value\":\"Bootstrap Tutorial Web Server\",\"Key\":\"Name\"}]}",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "WebServerSecurityGroup-CREATE_COMPLETE-2025-08-21T22:37:28.803Z",
"StackName": "my-stack",
"LogicalResourceId": "WebServerSecurityGroup",
"PhysicalResourceId": "my-stack-WebServerSecurityGroup-n8A43bQT1ty2",
"ResourceType": "AWS::EC2::SecurityGroup",
"Timestamp": "2025-08-21T22:37:28.803000+00:00",
"ResourceStatus": "CREATE_COMPLETE",
"ResourceProperties": "{\"GroupDescription\":\"Allow HTTP access from my IP address\",\"SecurityGroupIngress\":[{\"CidrIp\":\"0.0.0.0/0\",\"Description\":\"HTTP\",\"FromPort\":\"80\",\"ToPort\":\"80\",\"IpProtocol\":\"tcp\"}]}",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "WebServerSecurityGroup-CREATE_IN_PROGRESS-2025-08-21T22:37:22.626Z",
"StackName": "my-stack",
"LogicalResourceId": "WebServerSecurityGroup",
"PhysicalResourceId": "my-stack-WebServerSecurityGroup-n8A43bQT1ty2",
"ResourceType": "AWS::EC2::SecurityGroup",
"Timestamp": "2025-08-21T22:37:22.626000+00:00",
"ResourceStatus": "CREATE_IN_PROGRESS",
"ResourceStatusReason": "Resource creation Initiated",
"ResourceProperties": "{\"GroupDescription\":\"Allow HTTP access from my IP address\",\"SecurityGroupIngress\":[{\"CidrIp\":\"0.0.0.0/0\",\"Description\":\"HTTP\",\"FromPort\":\"80\",\"ToPort\":\"80\",\"IpProtocol\":\"tcp\"}]}",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "WebServerSecurityGroup-CREATE_IN_PROGRESS-2025-08-21T22:37:20.186Z",
"StackName": "my-stack",
"LogicalResourceId": "WebServerSecurityGroup",
"PhysicalResourceId": "",
"ResourceType": "AWS::EC2::SecurityGroup",
"Timestamp": "2025-08-21T22:37:20.186000+00:00",
"ResourceStatus": "CREATE_IN_PROGRESS",
"ResourceProperties": "{\"GroupDescription\":\"Allow HTTP access from my IP address\",\"SecurityGroupIngress\":[{\"CidrIp\":\"0.0.0.0/0\",\"Description\":\"HTTP\",\"FromPort\":\"80\",\"ToPort\":\"80\",\"IpProtocol\":\"tcp\"}]}",
"ClientRequestToken": "token"
},
{
"StackId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"EventId": "64740fe0-7edf-11f0-8a36-06453a64f325",
"StackName": "my-stack",
"LogicalResourceId": "my-stack",
"PhysicalResourceId": "arn:aws:cloudformation:aws-region:123456789012:stack/my-stack/64726230-7edf-11f0-8a36-06453a64f325",
"ResourceType": "AWS::CloudFormation::Stack",
"Timestamp": "2025-08-21T22:37:17.819000+00:00",
"ResourceStatus": "CREATE_IN_PROGRESS",
"ResourceStatusReason": "User Initiated",
"ClientRequestToken": "token"
}
]
}
```
最新のイベントが先頭に表示されます。次の表は、**describe-stack-events** コマンドによって返されるフィールドとその説明です。
| フィールド | 説明 |
| --- | --- |
| EventId | イベントの識別子 |
| StackName | イベントに対応するスタックの名前 |
| StackId | イベントに対応するスタックの識別子 |
| LogicalResourceId | リソースの論理識別子 |
| PhysicalResourceId | リソースの物理識別子 |
| ResourceProperties | リソースのプロパティ |
| ResourceType | リソースのタイプ。 |
| Timestamp | イベントが発生した時刻 |
| ResourceStatus | リソースのステータスは、以下のステータスコードのいずれかになります。`CREATE_COMPLETE` \$1 `CREATE_FAILED` \$1 `CREATE_IN_PROGRESS` \$1 `DELETE_COMPLETE` \$1 `DELETE_FAILED` \$1 `DELETE_IN_PROGRESS` \$1 `DELETE_SKIPPED` \$1 `IMPORT_COMPLETE` \$1 `IMPORT_IN_PROGRESS` \$1 `IMPORT_ROLLBACK_COMPLETE` \$1 `IMPORT_ROLLBACK_FAILED` \$1 `IMPORT_ROLLBACK_IN_PROGRESS` \$1 `REVIEW_IN_PROGRESS` \$1 `ROLLBACK_COMPLETE` \$1 `ROLLBACK_FAILED` \$1 `ROLLBACK_IN_PROGRESS` \$1 `UPDATE_COMPLETE` \$1 `UPDATE_COMPLETE_CLEANUP_IN_PROGRESS` \$1 `UPDATE_FAILED` \$1 `UPDATE_IN_PROGRESS` \$1 `UPDATE_ROLLBACK_COMPLETE` \$1 `UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS` \$1 `UPDATE_ROLLBACK_FAILED` \$1 `UPDATE_ROLLBACK_IN_PROGRESS` `DELETE_SKIPPED` ステータスは、削除ポリシー属性が保持になっているリソースに適用されます。 |
| DetailedStatus | スタックの詳細ステータス。`CONFIGURATION_COMPLETE` が存在する場合、スタックリソースの設定フェーズは完了済みで、リソースの安定化が進行中です。 |
| ResourceStatusReason | ステータスの詳細 |
## スタックステータスコード
次の表は、スタックステータスコードの説明です。
| スタックステータスと、オプションの詳細ステータス | 説明 |
| --- | --- |
| `CREATE_COMPLETE` | 1 つ以上のスタックを正常に作成。 |
| `CREATE_IN_PROGRESS` | 1 つ以上のスタックを作成中。 |
| `CREATE_FAILED` | 1 つ以上のスタックの作成に失敗。関連するエラーメッセージを確認するには、スタックのイベントを調べます。作成の失敗の理由としては、スタックのすべてのリソースを操作するためのアクセス許可の不足、AWS サービスによるパラメーター値の拒否、リソース作成中のタイムアウトなどが考えられます。 |
| `DELETE_COMPLETE` | 1 つ以上のスタックを正常に削除。削除されたスタックは、90 日間は保持され、表示できます。 |
| `DELETE_FAILED` | 1 つ以上のスタックの削除に失敗。削除が失敗したので、まだ実行されているリソースがいくつかある可能性があります。ただし、スタックを操作したり、更新したりすることはできません。スタックを再度削除するか、スタックのイベントを調べて関連するエラーメッセージを確認します。 |
| `DELETE_IN_PROGRESS` | 1 つ以上のスタックを削除中。 |
| `REVIEW_IN_PROGRESS` | 進行中の、予測される StackId を持つがテンプレートまたはリソースのない 1 つ以上のスタックの作成。 このステータスコードのスタックは、[スタックの可能な限りの最大数](cloudformation-limits.md)に対してカウントされます。 |
| `ROLLBACK_COMPLETE` | スタックの作成の失敗後、またはスタックの作成の明示的なキャンセル後に、1 つ以上のスタックを正常に削除。スタックは以前の動作状態に戻ります。スタック作成オペレーションの実行中に作成されたすべてのリソースが削除されます。 このステータスが存在するのは、スタックの作成が失敗した後のみです。部分的に作成されたスタックからすべてのオペレーションが適切にクリーンアップされたことを示します。この状態では、削除オペレーションのみを実行できます。 |
| `ROLLBACK_FAILED` | スタックの作成の失敗後、またはスタックの作成の明示的なキャンセル後に、1 つ以上のスタックの削除に失敗。スタックを削除するか、スタックのイベントを調べて関連するエラーメッセージを確認します。 |
| `ROLLBACK_IN_PROGRESS` | スタックの作成の失敗後、またはスタックの作成の明示的なキャンセル後に、1 つ以上のスタックを削除中。 |
| `UPDATE_COMPLETE` | 1 つ以上のスタックを正常に更新。 |
| `UPDATE_COMPLETE_CLEANUP_IN_PROGRESS` | スタックの正常な更新後に、1 つ以上のスタックの古いリソースを削除中。リソースの置き換えが必要なスタック更新の場合、CloudFormation はまず新しいリソースを作成し、次に古いリソースを削除して、スタックの中断を減らすことに役立ちます。この状態では、スタックは更新済みで使用可能ですが、CloudFormation はまだ古いリソースを削除中です。 |
| `UPDATE_FAILED` | 1 つ以上のスタックの失敗した更新。関連するエラーメッセージを確認するには、スタックのイベントを調べます。 |
| `UPDATE_IN_PROGRESS` | 1 つ以上のスタックを更新中。 |
| `UPDATE_ROLLBACK_COMPLETE` | スタックの更新の失敗後、1 つ以上のスタックを前の動作状態に正常に戻しました。 |
| `UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS` | スタックの更新の失敗後、1 つ以上のスタックの新しいリソースを削除中。この状態では、スタックが前の動作状態にロールバックされて使用可能ですが、CloudFormation がスタックの更新中に作成した新しいリソースをまだ削除中です。 |
| `UPDATE_ROLLBACK_FAILED` | スタックの更新の失敗後、1 つ以上のスタックを前の動作ステートに戻すことに失敗。この状態の場合は、スタックを削除するか、[ロールバックを続行する](using-cfn-updating-stacks-continueupdaterollback.md)ことができます。スタックが動作状態に戻るには、エラーを修正する必要がある場合があります。または、サポート に連絡してスタックを使用可能な状態に復元することができます。 |
| `UPDATE_ROLLBACK_IN_PROGRESS` | スタックの更新の失敗後、1 つ以上のスタックを前の動作状態に戻しています。 |
| `IMPORT_IN_PROGRESS` | インポートオペレーションは現在進行中です。 |
| `IMPORT_COMPLETE` | `resource import` をサポートするスタック内のすべてのリソースについて、インポート操作が正常に完了しました。 |
| `IMPORT_ROLLBACK_IN_PROGRESS` | インポートは、以前のテンプレート構成にロールバックされます。 |
| `IMPORT_ROLLBACK_FAILED` | スタック内の少なくとも 1 つのリソースに対するインポートのロールバックオペレーションが失敗しました。正常にインポートされたリソース CloudFormation の結果が利用可能になります。 |
| `IMPORT_ROLLBACK_COMPLETE` | インポートは、以前のテンプレート構成に正常にロールバックされました。 |
# オペレーション別にスタックイベントを表示する
オペレーション別にグループ化されたスタックイベントを表示して、スタックに加えられた変更のシーケンスと範囲をより良く理解できます。オペレーションベースのグループ化は、関連するイベントをまとめて追跡するのに役立つため、進行状況のモニタリングや問題発生時のトラブルシューティングが容易になります。
各スタックオペレーション (作成、更新、削除、ロールバック) には、すべての関連するイベントをグループ化する一意のオペレーション ID が割り当てられます。これにより、特定のオペレーションに焦点を当て、障害の根本原因をすばやく特定できます。
**Topics**
+ [
## 前提条件
](#view-stack-events-by-operation-prerequisites)
+ [
## オペレーション別にスタックイベントを表示する (コンソール)
](#view-stack-events-by-operation-console)
+ [
## オペレーション別にスタックイベントを表示する (AWS CLI)
](#view-stack-events-by-operation-cli)
+ [
## スタックステータスコード
](#stack-status-codes)
## 前提条件
`DescribeEvents` API を使用するには、`DescribeEvents` に必要な IAM アクセス許可が必要です。
## オペレーション別にスタックイベントを表示する (コンソール)
**オペレーション別にグループ化されたスタックイベントを表示するには**
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. 画面の上部のナビゲーションバーで、スタックを作成した AWS リージョンを選択します。
1. [**スタック**] ページで、スタック名を選択します。CloudFormation は選択したスタックのスタック詳細を表示します。
1. **[イベント]** タブを選択して、スタックのために CloudFormation が生成したスタックイベントを表示します。
1. イベントはオペレーション ID によって自動的にグループ化されます。各オペレーションは、オペレーションタイプ、ステータス、およびタイムスタンプを示す展開可能なセクションとして表示されます。
1. **オペレーション ID** をクリックして、その特定のオペレーションに関連するイベントのみを示す詳細なビューを開きます。
1. オペレーションの詳細ビューで、**[障害のみを表示]** チェックボックスを選択して、根本原因分析のために失敗したイベントのみを表示します。
CloudFormation は、スタックイベントを 1 分ごとに自動的に更新します。新しいスタックイベントが発生すると、**使用可能な新しいイベント**バッジが表示されます。更新アイコンを選択して、これらのイベントをリストにロードします。
オペレーションごとにグループ化されたスタックイベントを表示することで、各オペレーションのイベントのシーケンスを理解し、どの特定のオペレーションが問題を引き起こしたかをすばやく特定できます (スタックをデバッグしている場合)。
スタックオペレーションの実行中に、`CREATE_IN_PROGRESS`、`UPDATE_IN_PROGRESS`、または `DELETE_IN_PROGRESS` のステータスで一覧表示されます。オペレーションが正常に完了すると、そのステータスは `CREATE_COMPLETE`、`UPDATE_COMPLETE`、または `DELETE_COMPLETE` に変わります。
詳細については、「[CloudFormation スタック作成イベントを理解する](stack-resource-configuration-complete.md)」および「[スタック更新の進行状況を監視する](using-cfn-updating-stacks-monitor-stack.md)」を参照してください。
## オペレーション別にスタックイベントを表示する (AWS CLI)
コマンド `describe-events` をオペレーション ID フィルタリングとともに使用して、特定のオペレーションのイベントを表示できます。
### 最後のオペレーション ID を取得する
describe-stacks API を介して利用可能なスタックの説明に、最近のオペレーション ID とそのタイプを示す LastOperations 情報が含まれるようになりました。これにより、イベントログを通じて解析することなく、発生したオペレーションとその現在のステータスをすばやく特定できます。
```
aws cloudformation describe-stacks --stack-name MyStack
```
以下は、失敗した更新オペレーション後の最後のオペレーションがロールバックであったことを示すレスポンスの例です。
```
{
"Stacks": [
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/MyStack/07580010-bb79-11f0-8f6c-0289bb5c804f",
"StackName": "MyStack",
"Description": "A simple CloudFormation template to create an S3 bucket.",
"CreationTime": "2025-11-07T01:28:13.778000+00:00",
"LastUpdatedTime": "2025-11-07T01:43:39.838000+00:00",
"RollbackConfiguration": {},
"StackStatus": "UPDATE_ROLLBACK_COMPLETE",
"DisableRollback": false,
"NotificationARNs": [],
"Tags": [],
"EnableTerminationProtection": false,
"DriftInformation": {
"StackDriftStatus": "NOT_CHECKED"
},
"LastOperations": [
{
"OperationType": "ROLLBACK",
"OperationId": "d0f12313-7bdb-414d-a879-828a99b36f29"
},
{
"OperationType": "UPDATE_STACK",
"OperationId": "1c211b5a-4538-4dc9-bfed-e07734371e57"
}
]
}
]
}
```
### オペレーション ID でイベントをフィルタリングする
次の `describe-events` コマンドは、特定のオペレーション ID のイベントについて説明します。
```
aws cloudformation describe-events \
--operation-id 1c211b5a-4538-4dc9-bfed-e07734371e57
```
トラブルシューティングで失敗したイベントのみを表示するには、`--filter FailedEvents=true` パラメータを使用します。
```
aws cloudformation describe-events \
--operation-id 1c211b5a-4538-4dc9-bfed-e07734371e57 \
--filter FailedEvents=true
```
新しいオペレーション ID フィルタリング機能を使用すると、特定のオペレーションとその関連するイベントに焦点を当てることができます。これは特に以下の場合に便利です。
+ **特定の障害のトラブルシューティング:** 失敗したオペレーションからイベントを分離して、何が問題だったのかを理解します。
+ **実行時間が長いオペレーションのモニタリング:** 複雑な更新や大規模なスタックデプロイの進行状況を追跡します。
+ **変更の監査:** 特定の更新オペレーションに関連付けられているすべてのイベントを確認します。
+ **根本原因の分析:** 障害フィルターを使用して、デプロイの問題の原因をすばやく特定します。
## スタックステータスコード
次の表は、オペレーション ID フィルタリングを使用しているときに `describe-events` コマンドによって返されるフィールドを説明しています。
| フィールド | 説明 |
| --- | --- |
| EventId | イベントの識別子 |
| OperationId | このイベントを生成したオペレーションの一意の ID。 |
| StackName | イベントに対応するスタックの名前 |
| StackId | イベントに対応するスタックの識別子 |
| LogicalResourceId | リソースの論理識別子 |
| PhysicalResourceId | リソースの物理識別子 |
| ResourceProperties | リソースのプロパティ |
| ResourceType | リソースのタイプ。 |
| Timestamp | イベントが発生した時刻 |
| ResourceStatus | リソースのステータス (CREATE\$1COMPLETE、UPDATE\$1FAILED など)。 |
| DetailedStatus | スタックの詳細ステータス。CONFIGURATION\$1COMPLETE が存在する場合、スタックリソースの設定フェーズは完了済みで、リソースの安定化が進行中です。 |
| ResourceStatusReason | ステータスの詳細 |
# CloudFormation スタックデプロイのタイムラインを表示する
スタックデプロイタイムライングラフは、スタックデプロイタイムラインの視覚的な表現を提供します。このビューでは、スタックとその各リソースのデプロイステータス、および各ステータスが変更された時刻が示されます。スタックのデプロイステータスは、対応する色で表されます。
**Topics**
+ [
## スタックデプロイタイムライングラフについて
](#understanding-stack-deployment-timeline-graph)
+ [
## スタックデプロイタイムライングラフの表示 (コンソール)
](#viewing-stack-deployment-timeline-graph)
## スタックデプロイタイムライングラフについて
次の画像は、起動に失敗した Amazon EC2 インスタンスリソースを理由として失敗したスタックデプロイのタイムライングラフを示しています。
![\[失敗したスタックデプロイのスタックデプロイタイムライングラフ。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/deployment-timeline-graph.PNG)
スタックリソースの名前はグラフの左側にあり、デプロイ時刻に関連する日時はグラフの上部にあります。
各リソースは、**[進行中]** ステータスで始まります。デプロイが成功するたびに、ステータスバーは **[完了]** に変わります。リソースのデプロイに失敗すると、ステータスバーは **[失敗]** に変わります。リソースのデプロイに失敗し、スタックのデプロイにも失敗すると、スタックのデプロイの失敗を引き起こしたリソースは、**[ルート失敗の可能性]** ステータスを受け取ります。
スタックのデプロイオペレーションが失敗すると、正常にデプロイされたリソースはロールバックを開始し、**[ロールバックが進行中]** ステータスに変わります。リソースのロールバックが完了すると、ステータスは **[ロールバックが完了]** に変わります。
各リソースを選択すると、デプロイタイムラインのさらにきめ細かい詳細が表示されます:
![\[選択された失敗したリソースのデプロイの詳細を示すスタックデプロイタイムライングラフのポップオーバー。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/deployment-timeline-graph-root-cause.PNG)
リソースを選択すると、**[タイプ]**、デプロイの **[開始時刻]**、デプロイの **[終了時刻]**、デプロイの **[合計時間]** が表示されます。また、以下のドロップダウンメニューには、各デプロイステータスの **[開始時刻]**、**[終了時刻]**、**[期間]** も表示されます。リソースのデプロイに失敗した場合、**[失敗の理由]** が表示されます。
スタックステータスの詳細については、「[スタックステータスコード](view-stack-events.md#cfn-console-view-stack-data-resources-status-codes)」を参照してください。
## スタックデプロイタイムライングラフの表示 (コンソール)
スタックデプロイタイムライングラフを表示するには:
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 画面の上部のナビゲーションバーで、スタックを作成した AWS リージョンを選択します。
1. CloudFormation コンソールの **[Stacks]** (スタック) ページで、スタック名を選択します。CloudFormation は選択したスタックのスタック詳細を表示します。
1. **[イベント]** タブを選択して、スタックのために CloudFormation が生成したスタックイベントを表示します。
1. **[タイムライングラフ]** ボタンを選択すると、スタックのタイムライングラフが表示されます。
# CloudFormation スタック作成イベントを理解する
スタックのデプロイ中は、スタックテンプレートに定義されているリソースを作成、設定、および検証するためのイベントがいくつか発生します。これらのイベントを理解することは、スタック作成プロセスを最適化し、デプロイを合理化するために役立ちます。
+ **リソース作成イベント** – 各リソースが作成プロセスを開始すると、`CREATE_IN_PROGRESS` イベントの **[ステータス]** が設定されます。このイベントは、リソースがプロビジョニングされていることを示します。
+ **結果整合性チェック** – スタック作成時間の大部分は、スタックによって作成されたリソースに対する結果整合性チェックの実行に費やされます。このフェーズでは、サービスが内部整合性チェックを実行して、リソースが完全に機能し、各 AWS のサービスが定義するサービス安定化基準を満たしていることを確認します。
+ **設定完了イベント** – 各リソースがプロビジョニングの結果整合性チェックフェーズを完了すると、`CONFIGURATION_COMPLETE` イベントの **[詳細ステータス]** が設定されます。
+ **リソース作成完了イベント** – リソースが指定されたとおりに作成および設定され、設定がテンプレートで指定されたものと一致すると、`CREATE_COMPLETE` イベントの **[ステータス]** が設定されます。
本番稼働前のスタック設定やクロススタックプロビジョニングの検証など、リソースの結果整合性チェックが不要なシナリオでは、`CONFIGURATION_COMPLETE` イベントを活用してスタック作成プロセスを合理化できます。このイベントは複数の方法で使用できます。例えば、視覚的なシグナルとして使用することで、リソースまたはスタックの整合性チェックの終了を待たずに済みます。または、継続的インテグレーションと継続的デリバリー (CI/CD) を使用して自動メカニズムを作成し、追加のアクションをトリガーすることもできます。
**重要**
`CONFIGURATION_COMPLETE` イベントを利用するとスタックの作成時間が短縮されますが、そのトレードオフに注意する必要があります。まず、サポートされているのは、ドリフト検出をサポートする一部のリソースタイプのみです。ドリフト検出をサポートするリソースタイプのリストについては、「[リソースタイプのサポート](resource-import-supported-resources.md)」を参照してください。このアプローチは、クラウド環境全体 (本番環境など) の運用準備を完全に確保するために、リソースが徹底的な結果整合性チェックを必要とするシナリオには適さない場合があります。デプロイ要件と各リソースの整合性チェックの重要性を慎重に評価することをお勧めします。`CONFIGURATION_COMPLETE` イベントを使用して、インフラストラクチャの整合性と信頼性を損なうことなく、デプロイ速度を最適化します。
`CONFIGURATION_COMPLETE` イベントの設定は保証されないため、`CONFIGURATION_COMPLETE` イベントが設定済みでない場合は、それを使用するシナリオで `CREATE_COMPLETE` イベントを処理する準備を整える必要があります。
![\[スタック内のリソース作成と結果整合性チェックのイベントのシーケンスを示す図。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/configuration-complete.png)
スタックのデプロイが開始されると、リソース `AWS::ECR::Repository` および `AWS::ECS::Cluster` が作成プロセスを開始します (`ResourceStatus` = `CREATE_IN_PROGRESS`)。`AWS::ECR::Repository` リソースタイプによって結果整合性チェックが開始されると (`DetailedStatus` = `CONFIGURATION_COMPLETE`)、`AWS::ECS::TaskDefinition` リソースは作成プロセスを開始できるようになります。同様に、`AWS::ECS::TaskDefinition` リソースが結果整合性チェックを開始すると、`AWS::ECS::Service` リソースは作成プロセスを開始します。
**`CREATE_IN_PROGRESS` イベントと `CREATE_COMPLETE` イベント**
+ **[スタック]:** `CREATE_IN_PROGRESS`
+ **[リソース]:** ECR リポジトリ `CREATE_IN_PROGRESS`
+ **[リソース]:** ECS クラスター `CREATE_IN_PROGRESS`
+ **[リソース]:** ECR リポジトリ`CREATE_IN_PROGRESS`、`CONFIGURATION_COMPLETE`
+ **[リソース]:** ECS タスク定義 `CREATE_IN_PROGRESS`
+ **[リソース]:** ECS クラスター`CREATE_IN_PROGRESS`、`CONFIGURATION_COMPLETE`
+ **[リソース]:** ECS タスク定義 `CREATE_IN_PROGRESS`、`CONFIGURATION_COMPLETE`
+ **[リソース]:** ECS サービス `CREATE_IN_PROGRESS`
+ **[リソース]:** ECR リポジトリ `CREATE_COMPLETE`
+ **[リソース]:** ECS クラスター `CREATE_COMPLETE`
+ **[リソース]:** ECS サービス `CREATE_IN_PROGRESS`、`CONFIGURATION_COMPLETE`
+ **[スタック]:** `CREATE_IN_PROGRESS`、`CONFIGURATION_COMPLETE`
+ **[リソース]:** ECS タスク定義 `CREATE_COMPLETE`
+ **[リソース]:** ECS サービス `CREATE_COMPLETE`
+ **[スタック]:** `CREATE_COMPLETE`
# スタック更新の進行状況を監視する
スタックのイベントを表示して、スタック更新の進行状況を監視できます。スタックの **[イベント]** タブには、スタックの作成と更新における各主要ステップが、各イベントの時間順 (最新イベントが最上位) に表示されます。詳細については、「[スタックの進行状況を監視する](monitor-stack-progress.md)」を参照してください。
**Topics**
+ [
## スタックの正常な更新中に生成されたイベント
](#using-cfn-updating-stacks-monitor-stack-update-events)
+ [
## リソース更新が失敗したときに生成されるイベント
](#using-cfn-updating-stacks-monitor-stack-update-failure)
## スタックの正常な更新中に生成されたイベント
スタックの更新プロセスの開始は、スタックの `UPDATE_IN_PROGRESS` イベントでマークされます。
```
2011-09-30 09:35 PDT AWS::CloudFormation::Stack MyStack UPDATE_IN_PROGRESS
```
次のイベントは、更新されたテンプレートで変更された各リソースの更新の開始と完了をマークするイベントです。例えば、`MyDB` という名前の [https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-rds-dbinstance.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-rds-dbinstance.html) リソースの更新は、次のようなエントリになります。
```
2011-09-30 09:35 PDT AWS::RDS::DBInstance MyDB UPDATE_COMPLETE
2011-09-30 09:35 PDT AWS::RDS::DBInstance MyDB UPDATE_IN_PROGRESS
```
CloudFormation がリソースの更新を開始したことがレポートされると、`UPDATE_IN_PROGRESS` イベントが記録されます。リソースが正常に作成されると、`UPDATE_COMPLETE` イベントが記録されます。
CloudFormation がスタックを正常に更新すると、以下のイベントが表示されます。
```
2011-09-30 09:35 PDT AWS::CloudFormation::Stack MyStack UPDATE_COMPLETE
```
**重要**
スタックの更新オペレーション中に、CloudFormation が既存のリソースを置き換える必要がある場合、最初に新しいリソースを作成し、次に古いリソースを削除します。ただし、CloudFormation が古いリソースを削除できない場合があります (例えば、ユーザーが特定のタイプのリソースを削除するためのアクセス権限を持っていない場合)。
CloudFormation は、古いリソースの削除を 3 回試みます。CloudFormation が古いリソースを削除できない場合、古いリソースをスタックから削除し、スタックの更新を続行します。スタックの更新が完了すると、CloudFormation は `UPDATE_COMPLETE` スタックイベントを発行しますが、1 つ以上のリソースを削除できなかったことを示す `StatusReason` が含まれます。CloudFormation は、特定のリソースに対して `DELETE_FAILED` イベントを発行し、対応する `StatusReason` は CloudFormation がリソースの削除に失敗した理由の詳細を提供します。
古いリソースはまだ存在し、引き続き課金されますが、CloudFormation からはアクセスできなくなります。古いリソースを削除するには、基盤となるサービスのコンソールまたは API を使用して、古いリソースに直接アクセスします。
これは、スタックテンプレートから削除したリソースにも当てはまります。そのため、スタックの更新中にスタックから削除されます。
## リソース更新が失敗したときに生成されるイベント
リソースの更新が失敗した場合、CloudFormation は失敗の理由を含めた `UPDATE_FAILED` イベントを報告します。例えば、[https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-rds-dbinstance.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-rds-dbinstance.html) リソースの `AllocatedStorage` サイズの減少など、リソースでサポートされていないプロパティ変更を更新テンプレートで指定した場合、次のようなイベントが表示されます。
```
2011-09-30 09:36 PDT AWS::RDS::DBInstance MyDB UPDATE_FAILED Size cannot be less than current size; requested: 5; current: 10
2011-09-30 09:35 PDT AWS::RDS::DBInstance MyDB UPDATE_IN_PROGRESS
```
リソース更新が失敗した場合、CloudFormation はアップグレード中に更新したすべてのリソースを、更新前の設定にロールバックします。更新のロールバック中に表示されるイベントの例を次に示します。
```
2011-09-30 09:38 PDT AWS::CloudFormation::Stack MyStack UPDATE_ROLLBACK_COMPLETE
2011-09-30 09:38 PDT AWS::RDS::DBInstance MyDB UPDATE_COMPLETE
2011-09-30 09:37 PDT AWS::RDS::DBInstance MyDB UPDATE_IN_PROGRESS
2011-09-30 09:37 PDT AWS::CloudFormation::Stack MyStack UPDATE_ROLLBACK_IN_PROGRESS The following resource(s) failed to update: [MyDB]
```
# 更新のロールバックを続ける
時折、CloudFormation がスタック更新のロールバックを試みるときに、更新プロセス中に行ったすべての変更をロールバックできない場合があります。これは、`UPDATE_ROLLBACK_FAILED` 状態と呼ばれます。例えば、CloudFormation の外部で削除された古いデータベースのインスタンスにロールバックを開始するスタックがある場合などです。CloudFormation にはデータベースが削除されたことがわからないため、データベースインスタンスがまだ存在する前提でそれにロールバックしようとし、更新のロールバックが失敗します。
`UPDATE_ROLLBACK_FAILED` 状態のスタックは更新できませんが、動作状態 (`UPDATE_ROLLBACK_COMPLETE`) にロールバックできます。スタックを元の設定に戻すと、もう一度更新を試行することができます。
ほとんどの場合、スタックのロールバックを続けるには、更新のロールバックが失敗する原因となるエラーを修正する必要があります。それ以外の場合(たとえば、スタック操作のタイムアウト)では、変更を加えずに更新のロールバックを続けることができます。
**注記**
ネストされたスタックを使用する場合には、親スタックをロールバックすると、すべての子スタックも同じような転送を試みます。
**更新のロールバックを続けるには (コンソール)**
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. 画面の上部のナビゲーションバーで、スタックが所在する AWS リージョン を選択します。
1. [**Stacks**] ページで、更新するスタックを選択し、[**スタックアクション**]、[**更新のロールバックの続行**] の順に選択します。
[エラーのトラブルシューティング](troubleshooting.md#troubleshooting-errors) の解決策でも解決できなかった場合は、高度なオプションを使用して、CloudFormation が正常にロールバックできないリソースをスキップできます。スキップするリソースの論理 ID を[検索](cfn-console-view-stack-data-resources.md)して入力する必要があります。更新の転送中ではなく、`UpdateRollback` 中に `UPDATE_FAILED` 状態になったリソースのみを指定します。
**警告**
CloudFormation は指定されたリソースのステータスを `UPDATE_COMPLETE` に設定し、引き続きスタックをロールバックします。ロールバックが完了したら、スキップされたリソースのステータスはスタックテンプレートのリソースのステータスと一致しません。別のスタックの更新を実行する前に、スタックまたはリソースを更新して、整合性を取る必要があります。そうしないと、以降のスタックの更新が失敗して、スタックが回復不可能になる可能性があります。
スタックを正常にロールバックするために必要なリソースの最小数を指定します。たとえば、あるリソース更新が失敗したために、それに依存するリソースが失敗することがあります。この場合、依存リソースをスキップする必要はない可能性があります。
ネストされたスタックの一部であるリソースをスキップするには、次の形式を使用します: `NestedStackName.ResourceLogicalID`。`ResourcesToSkip` リストでスタックリソース (`Type: AWS::CloudFormation::Stack`) の論理 ID を指定する場合、対応する組み込みスタックは以下のいずれかの状態である必要があります: `DELETE_IN_PROGRESS`、`DELETE_COMPLETE`、または `DELETE_FAILED`。
**更新のロールバックを続けるには (AWS CLI)**
+ ロールバックを続けるスタックの ID を指定するために、[https://docs.aws.amazon.com/cli/latest/reference/cloudformation/continue-update-rollback.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/continue-update-rollback.html) コマンドで `--stack-name` オプションを使用します。
## 失敗した、ネストされたスタックの更新からのロールバックを続ける
複数のスタックが互いにネストされている場合、複数のネストレベル全体でリソースをスキップして、スタック階層全体を動作状態に戻す必要がある場合があります。
例えば、`WebInfra` というルートスタックがあり、その中に `WebInfra-Compute` と `WebInfra-Storage` の 2 つの小さなスタックが含まれているとします。これらの 2 つのスタック内にも、独自のネストされたスタックがあります。
更新中に問題が発生し、更新プロセスが失敗した場合、次の図に示すように、スタック階層全体が `UPDATE_ROLLBACK_FAILED` 状態になる可能性があります。
![\[3 レベルのネストされたスタック階層を示す図です。\]](http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/images/cfn-update-stack-continue-update-rollback_nested-stacks.png)
**注記**
この例でスタック名は単純にするために切り捨てられています。子スタック名は通常 CloudFormation によって生成され、一意のランダムな文字列を含んでいるため、実際の名前はユーザーフレンドリーではない可能性があります。
`continue-update-rollback` コマンドを使用してルートスタックを操作可能な状態にするには、`--resources-to-skip` オプションを使用して、ロールバックに失敗したリソースをスキップする必要があります。
以下の **continue-update-rollback** の例は、前回失敗したスタック更新からのロールバック操作を再開します。この例では、`--resources-to-skip` オプションには次の項目が含まれます。
+ `myCustom`
+ `WebInfra-Compute-Asg.myAsg`
+ `WebInfra-Compute-LB.myLoadBalancer`
+ `WebInfra-Storage.DB`
ルートスタックのリソースの場合、必要なのは論理 ID を指定することだけです (例: `myCustom`)。ただし、ネストされたスタックに含まれるリソースについては、ネストされたスタック名とその論理 ID の両方をピリオドで区切って指定する必要があります。例えば、`WebInfra-Compute-Asg.myAsg`。
```
aws cloudformation continue-update-rollback --stack-name WebInfra \
--resources-to-skip myCustom WebInfra-Compute-Asg.myAsg WebInfra-Compute-LB.myLoadBalancer WebInfra-Storage.DB
```
**ネストされたスタックのスタック名を検索するには**
子スタックのスタック ID または Amazon リソースネーム (ARN) 内で見つけることができます。
次の ARN の例は、`WebInfra-Storage-Z2VKC706XKXT` という名前のスタックを参照しています。
```
arn:aws:cloudformation:us-east-1:123456789012:stack/WebInfra-Storage-Z2VKC706XKXT/ea9e7f90-54f7-11e6-a032-028f3d2330bd
```
**ネストされたスタックの論理 ID を検索するには**
子スタックの論理 ID は、親のテンプレート定義で検索できます。この図では、`WebInfra-Storage-DB` 子スタックの `LogicalId` は、親 `WebInfra-Storage` の `DB` です。
CloudFormation コンソールでは、**[Resources]** (リソース) タブ、または **[Events]** (イベント) タブのスタックリソースの **[Logical ID]** (論理 ID) 列で論理 ID を見つけることもできます。詳細については、「[CloudFormation コンソールからスタック情報を表示する](cfn-console-view-stack-data-resources.md)」を参照してください。
# スタックが失敗する原因を判断する
スタックの作成が失敗する場合は、CloudFormation がスタック失敗の根本原因である可能性が高いイベントの判断に役立ちます。シナリオと許可によっては、**[イベント]** で提供された **[ステータスの理由]** が明確でない場合でも、AWS CloudTrail イベントで根本原因に関する詳細情報を確認できる場合があります。
**スタックが失敗する根本原因を判断するには**
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. **[スタック]** ページで、失敗したスタックを選択します。
1. **[イベント]** タブを選択します。
1. **[根本原因を検出]** を選択します。CloudFormation は障害を分析し、特定のイベントの **[ステータス]** に **[考えられる根本原因]** ラベルを追加することで、障害の原因である可能性のあるイベントを示します。CloudFormation コンソールのステータスの詳細な説明については、**[ステータスの理由]** を表示します。
1. 失敗の原因の詳細については、**[考えられる根本原因]** ラベルが付いた **[失敗]** ステータスを選択します。シナリオと許可に応じて、詳細な CloudTrail イベントを確認できる場合があります。**[ステータス]** を選択すると、次のような結果が得られる可能性があります。
+ この問題に関連する CloudTrail イベントが使用可能であり、解決に役立つ可能性があります。CloudTrail イベントを表示します。
+ この問題に関連して解決に役立つ可能性のある CloudTrail イベントは見つかりませんでした。
+ 現在の許可は、CloudTrail イベントを表示するためのアクセスを許可していません。詳細はこちら。
+ 使用可能な CloudTrail イベントを確認しています。数分後にもう一度確認してください。
+ CloudTrail イベントの取得中にエラーが発生しました。手動で検査する場合は、CloudTrail コンソールにアクセスしてください。
1. **[ステータスの理由]** に示された理由が明確でなく、根本原因で CloudTrail コンソールへのリンクが表示されている場合は、リンクを開いてイベントを表示し、詳細な根本原因を見つけます。
CloudTrail イベントの詳細については、「[Understanding CloudTrail events](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-events.html)」および「[CloudTrail record contents](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html)」を参照してください。
CloudTrail イベント履歴の詳細については、「[Working with CloudTrail Event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
**注記**
ネストされたスタックは **[根本原因を検出]** をサポートしません。
# リソースのプロビジョニング時における失敗への対応方法を選択する
スタックオペレーションが失敗した場合でも、既に正常にプロビジョニングされたリソースを毎回ロールバックし、最初からやり直す必要はありません。その代わりに、`CREATE_FAILED` または `UPDATE_FAILED` ステータスのリソースをトラブルシューティングして、問題が発生した箇所からプロビジョニングを再開することができます。
これを行うには、[正常にプロビジョニングされたリソースの保持] オプションを有効にする必要があります。このオプションは、すべてのスタックデプロイと変更セットオペレーションで利用できます。
+ スタックの作成で **[正常にプロビジョニングされたリソースの保持]** オプションを選択すると、CloudFormation は正常に作成されたリソースの状態を保持しますが、失敗したリソースは次の更新オペレーションが実行されるまで失敗状態のままにしておきます。
+ 更新オペレーションや変更セットオペレーション中に **[正常にプロビジョニングされたリソースの保持]** を選択すると、成功状態のリソースが保持されると同時に、失敗したリソースが最後に認識された安定した状態にロールバックされます。失敗したリソースは `UPDATE_FAILED` 状態になります。最後の安定状態が確認されていないリソースは、次のスタックオペレーション時に削除されます。
**Topics**
+ [
## スタック障害オプションの概要
](#stack-failure-options-overview)
+ [
## スタックのロールバックを一時停止するために必要な条件
](#stack-failure-options-conditions)
+ [
## 正常にプロビジョニングされたリソースを保持する (コンソール)
](#stack-failure-options-console)
+ [
## 正常にプロビジョニングされたリソースを保持する (AWS CLI)
](#stack-failure-options-cli)
## スタック障害オプションの概要
CloudFormation コンソール、API、または AWS CLI からオペレーションを実行する前に、プロビジョニングされたリソースの失敗時の動作を指定します。次に、他の変更を加えずに、リソースのデプロイプロセスを続行します。運用上の障害が発生した場合、CloudFormation は各独立したプロビジョニングパスの最初の障害時に停止します。CloudFormation は、リソース間の依存関係を特定して、独立したプロビジョニングアクションを並列化します。その後、障害が発生するまで、各独立したプロビジョニングパスでリソースのプロビジョニングに進みます。1 つのパスで障害が発生しても、他のプロビジョニングパスには影響しません。CloudFormation は、完了するか、別の障害で停止するまで、リソースのプロビジョニングを続けます。
問題を修正してデプロイプロセスを続行します。CloudFormation は、以前に正常にプロビジョニングできなかったリソースに対するプロビジョニングアクションを再試行する前に、必要な更新を実行します。**[Retry]** (再試行)、**[Update]** (更新)、または **[Roll back]** (ロールバック) オペレーションを送信して、問題を修正します。例えば、Amazon EC2 インスタンスのプロビジョニング中に、EC2 インスタンスの作成オペレーション中に失敗した場合、失敗したリソースをすぐにロールバックするのではなく、そのエラーを調査する必要がある場合があります。システムステータスチェックとインスタンスステータスチェックを確認し、問題が解決したら **[Retry]** (再試行) オペレーションを選択できます。
スタックオペレーションが失敗し、**[Stack failure options]** (スタック障害のオプション) メニューから **[Preserve successfully provisioned resources]** (正常にプロビジョニングされたリソースの保存) を指定した場合、次のオプションを選択できます。
+ **[Retry]** (再試行) - 失敗したリソースでプロビジョニングオペレーションを再試行し、スタックオペレーションが正常に完了するか、次の失敗が発生するまでテンプレートのプロビジョニングを続行します。AWS Identity and Access Management (IAM) アクセス許可など、テンプレートの変更を必要としない問題が原因でリソースのプロビジョニングに失敗した場合に、このオプションを選択します。
+ **[Update]** (更新) - プロビジョニングされたリソースは、テンプレートの更新時に更新されます。作成または更新に失敗したリソースは再試行されます。テンプレートエラーが原因でリソースのプロビジョニングに失敗し、テンプレートを変更した場合は、このオプションを選択します。`FAILED` 状態にあるスタックを更新する場合、スタックの更新を続行するには、**[Stack failure options]** (スタックの障害オプション) で **[Preserve successfully provisioned resources]** (正常にプロビジョニングされたリソースを保持する) を選択する必要があります。
+ **[Roll back]** (ロールバック) - CloudFormation はスタックを最後の既知の安定状態にロールバックします。
## スタックのロールバックを一時停止するために必要な条件
CloudFormation が正常に作成されたリソースを自動的にロールバックして削除しないようにするには、次の条件を満たす必要があります。
1. スタックを作成または更新するときに、**[正常にプロビジョニングされたリソースの保持]** オプションを選択すること。そうすることで、スタックオペレーション全体が失敗した場合でも、正常に作成されたリソースは削除しないよう CloudFormation に指示します。
1. スタックオペレーションが失敗していること。つまり、スタックのステータスが `CREATE_FAILED` または `UPDATE_FAILED` である必要があります。
**注記**
不変の更新の種類はサポートされていません。
## 正常にプロビジョニングされたリソースを保持する (コンソール)
------
#### [ Create stack ]
**スタックの作成オペレーション中に正常にプロビジョニングされたリソースを保持するには**
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. **[スタック]** ページでは、右上の **[スタックの作成]** を選択してから、**[新しいリソースを使用 (標準)]** を選択します。
1. **[前提条件 - テンプレートの準備]** で、**[既存のテンプレートを選択]** を選択します。
1. [**Specify template (テンプレートの指定)**] で、スタックテンプレートを含む S3 バケットの URL を指定するか、スタックテンプレートファイルをアップロードするかを選択します。その後、**[Next]** を選択します。
1. **[Specify stack details]** (スタック詳細の指定) ページで、**[Stack name]** (スタックの名前) ボックスにスタック名を入力します。
1. **[Parameters]** (パラメータ) セクションで、スタックテンプレートで定義されているパラメータを指定します。
デフォルト値を持つパラメータを使用または変更できます。
1. パラメータ値が適切であることを確認したら、**[Next]** (次へ) を選択します。
1. **[Configure stack options]** (スタックオプションを設定する) ページでは、スタックのオプションを追加設定できます。
1. **[Stack failure options]** (スタック障害オプション) の場合、**[Preserve successfully provisioned resources]** (正常にプロビジョニングされたリソースを保持する) を選択します。
1. スタックオプションが適切であることを確認したら、**[Next]** (次へ) を選択します。
1. **[Review]** (確認) ページでスタックを確認し、**[Create stack]** (スタックの作成) を選択します。
結果: 作成に失敗したリソースは、スタックオペレーションで障害が発生したときにスタックがロールバックされないように、スタックステータスを `CREATE_FAILED` に移行します。正常にプロビジョニングされたリソースは、`CREATE_COMPLETE` 状態にあります。**[Stack events]** (スタックイベント) タブでスタックを監視できます。
------
#### [ Update stack ]
**スタックの更新オペレーション中に正常にプロビジョニングされたリソースを保持するには**
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. 更新するスタックを選択し、次に **[Update]** (更新)を選択します。
1. **[Update stack]** (スタックの更新) ページで、以下のいずれかのオプションを使用してスタックのテンプレートを選択します。
+ **既存のテンプレートを使用する**
+ **[Replace current template]** (現在のテンプレートを置換する)
+ **Infrastructure Composer でテンプレートを編集する**
設定を受け入れて、**[Next]** (次へ) を選択してください。
1. **[Specify stack details]** (スタックの詳細を指定する) ページで、スタックテンプレートで定義されているパラメータを指定します。
デフォルト値を持つパラメータを使用または変更できます。
1. パラメータ値が適切であることを確認したら、**[Next]** (次へ) を選択します。
1. **[Configure stack options]** (スタックオプションを設定する) ページでは、スタックのオプションを追加設定できます。
1. **[Behavior on provisioning failure]** (プロビジョニングの失敗時の動作) で、**[Preserve successfully provisioned resources]** (正常にプロビジョニングされたリソースを保持する) を選択します。
1. スタックオプションが適切であることを確認したら、**[Next]** (次へ) を選択します。
1. **[Review]** (確認) ページでスタックを確認し、**[Update stack]** (スタックの更新) を選択します。
結果: 更新に失敗したリソースは、スタックステータスを `UPDATE_FAILED` に移行させ、最後の既知の安定状態にロールバックします。最後の安定状態が確認されていないリソースは、次のスタックオペレーション時に CloudFormation によって削除されます。正常にプロビジョニングされたリソースは、`CREATE_COMPLETE` または `UPDATE_COMPLETE` 状態にあります。**[Stack events]** (スタックイベント) タブでスタックを監視できます。
------
#### [ Change set ]
**注記**
ステータスが `CREATE_FAILED` または `UPDATE_FAILED` のスタックに対して変更セットを開始できますが、ステータスが `UPDATE_ROLLBACK_FAILED` のスタックに対しては開始できません。
**変更セットオペレーション中に正常にプロビジョニングされたリソースを保持するには**
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. 開始する変更セットを含むスタックを選択し、**[Change sets]** (変更セット) タブを選択します。
1. 変更セットを選択し、**[Execute]** (実行) を選択します。
1. **[Execute change set]** (変更セットの実行) の場合、**[Preserve successfully provisioned resources]** (正常にプロビジョニングされたリソースを保持する) オプションを選択します。
1. **[Execute change set]** (変更セットの実行) を選択します。
結果: 更新に失敗したリソースは、スタックステータスを `UPDATE_FAILED` に移行させ、最後の既知の安定状態にロールバックします。最後の安定状態が確認されていないリソースは、次のスタックオペレーション時に CloudFormation によって削除されます。正常にプロビジョニングされたリソースは、`CREATE_COMPLETE` または `UPDATE_COMPLETE` 状態にあります。**[Stack events]** (スタックイベント) タブでスタックを監視できます。
------
## 正常にプロビジョニングされたリソースを保持する (AWS CLI)
------
#### [ Create stack ]
**スタックの作成オペレーション中に正常にプロビジョニングされたリソースを保持するには**
[create-stack](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html) オペレーション中に `--disable-rollback` オプションまたは `on-failure DO_NOTHING` 列挙を指定します。
1. **create-stack** コマンドに `--disable-rollback` オプションでスタック名とテンプレートを指定します。
```
aws cloudformation create-stack --stack-name myteststack \
--template-body file://template.yaml \
--disable-rollback
```
このコマンドは、以下の出力を返します。
```
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896"
}
```
1. **describe-stacks** コマンドを使用してスタックの状態を記述します。
```
aws cloudformation describe-stacks --stack-name myteststack
```
このコマンドは、以下の出力を返します。
```
{
"Stacks": [
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896",
"Description": "AWS CloudFormation Sample Template",
"Tags": [],
"Outputs": [],
"StackStatusReason": “The following resource(s) failed to create: [MyBucket]”,
"CreationTime": "2013-08-23T01:02:15.422Z",
"Capabilities": [],
"StackName": "myteststack",
"StackStatus": "CREATE_FAILED",
"DisableRollback": true
}
]
}
```
------
#### [ Update stack ]
**スタックの更新オペレーション中に正常にプロビジョニングされたリソースを保持するには**
1. **update-stack** コマンドに `--disable-rollback` オプションで既存のスタック名とテンプレートを指定します。
```
aws cloudformation update-stack --stack-name myteststack \
--template-url https://s3.amazonaws.com/amzn-s3-demo-bucket/updated.template --disable-rollback
```
このコマンドは、以下の出力を返します。
```
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896"
}
```
1. **describe-stacks** または **describe-stack-events** コマンドを使用してスタックの状態を記述します。
```
aws cloudformation describe-stacks --stack-name myteststack
```
このコマンドは、以下の出力を返します。
```
{
"Stacks": [
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896",
"Description": "AWS CloudFormation Sample Template",
"Tags": [],
"Outputs": [],
"CreationTime": "2013-08-23T01:02:15.422Z",
"Capabilities": [],
"StackName": "myteststack",
"StackStatus": "UPDATE_COMPLETE",
"DisableRollback": true
}
]
}
```
------
#### [ Change set ]
**注記**
ステータスが `CREATE_FAILED` または `UPDATE_FAILED` のスタックに対して変更セットを開始できますが、ステータスが `UPDATE_ROLLBACK_FAILED` のスタックに対しては開始できません。
**変更セットオペレーション中に正常にプロビジョニングされたリソースを保持するには**
[execute-change-set](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/execute-change-set.html) オペレーション中に `--disable-rollback` オプションを指定します。
1. **execute-change-set** コマンドに `--disable-rollback` オプションでスタック名とテンプレートを指定します。
```
aws cloudformation execute-change-set --stack-name myteststack \
--change-set-name my-change-set --template-body file://template.yaml
```
このコマンドは、以下の出力を返します。
```
{
"Id": "arn:aws:cloudformation:us-east-1:123456789012:changeSet/my-change-set/bc9555ba-a949-xmpl-bfb8-f41d04ec5784",
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896"
}
```
1. `--disable-rollback` オプションで変更セットを開始します。
```
aws cloudformation execute-change-set --stack-name myteststack \
--change-set-name my-change-set -–disable-rollback
```
1. **describe-stacks** または **describe-stack-events** コマンドを使用してスタックのステータスを確認します。
```
aws cloudformation describe-stack-events --stack-name myteststack
```
このコマンドは、以下の出力を返します。
```
{
"StackEvents": [
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896",
"EventId": "49c966a0-7b74-11ea-8071-024244bb0672",
"StackName": "myteststack",
"LogicalResourceId": " MyBucket",
"PhysicalResourceId": "myteststack-MyBucket-abcdefghijk1",
"ResourceType": "AWS::S3::Bucket",
"Timestamp": "2020-04-10T21:43:17.015Z",
"ResourceStatus": "UPDATE_FAILED"
"ResourceStatusReason": "User XYZ is not allowed to perform S3::UpdateBucket on MyBucket"
}
}
```
1. 権限エラーを修正してオペレーションを再試行してください。
```
aws cloudformation update-stack --stack-name myteststack \
--use-previous-template --disable-rollback
```
このコマンドは、以下の出力を返します。
```
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896"
}
```
1. **describe-stacks** または **describe-stack-events** コマンドを使用してスタックの状態を記述します。
```
aws cloudformation describe-stacks --stack-name myteststack
```
このコマンドは、以下の出力を返します。
```
{
"Stacks": [
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896",
"Description": "AWS CloudFormation Sample Template",
"Tags": [],
"Outputs": [],
"CreationTime": "2013-08-23T01:02:15.422Z",
"Capabilities": [],
"StackName": "myteststack",
"StackStatus": "UPDATE_COMPLETE",
"DisableRollback": true
}
]
}
```
------
### スタックをロールバックする
[rollback-stack](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/rollback-stack.html) コマンドを使用して、スタックステータスが `CREATE_FAILED` または `UPDATE_FAILED` のスタックを最後の安定した状態にロールバックできます。
以下の **rollback-stack** コマンドは、指定されたスタックをロールバックします。
```
aws cloudformation rollback-stack --stack-name myteststack
```
このコマンドは、以下の出力を返します。
```
{
"StackId": "arn:aws:cloudformation:us-east-1:123456789012:stack/myteststack/466df9e0-0dff-08e3-8e2f-5088487c4896"
}
```
**注記**
**rollback-stack** オペレーションは、スタックに最新の既知の安定状態が含まれていない場合、スタックを削除します。