CloudFormation のトラブルシューティング - AWS CloudFormation
トラブルシューティングガイドエラーのトラブルシューティング Support へのお問い合わせ

CloudFormation のトラブルシューティング

CloudFormation を使用するときは、CloudFormation スタックの作成、更新、または削除時に問題が発生する場合があります。以降のセクションは、発生する可能性のある一般的な問題のトラブルシューティングに役立ちます。

CloudFormation に関する一般的な質問については、「AWS CloudFormation のよくある質問」を参照してください。また、AWS re:Post の CloudFormation コミュニティで答えを探したり、質問を投稿したりすることもできます。

トラブルシューティングガイド

CloudFormation がスタックの作成、更新、または削除に失敗する場合は、問題に関する詳細情報の入手に役立つエラーメッセージやログを表示できます。ここでは、CloudFormation の問題をトラブルシューティングするための一般的な方法について説明します。特定のエラーと解決方法については、「エラーのトラブルシューティング」セクションを参照してください。

  • CloudFormation コンソールを使用して、スタックのステータスを表示します。コンソールには、スタックを作成、更新、または削除する際のスタックイベントのリストを表示できます。このリストから失敗イベントを探して、そのイベントのステータスの理由を確認します。ステータスの理由には、CloudFormation、または問題のトラブルシューティングに役立つ特定のサービスからのエラーメッセージが含まれている場合があります。スタックイベントの表示の詳細については、「CloudFormation スタックイベントを表示する」を参照してください。

  • Amazon EC2 の問題については、cloud-init および cfn のログを参照してください。これらのログは、/var/log/ ディレクトリの Amazon EC2 インスタンスに発行されます。これらのログは、CloudFormation がインスタンスをセットアップしているときのプロセスとコマンド出力をキャプチャします。Windows の場合、%ProgramFiles%\Amazon\EC2ConfigService で EC2Configure サービス、%ProgramData%\Amazon\EC2-Windows\Launch\Logs で EC2 Launch、%ProgramData%\Amazon\EC2Launch\log で EC2 Launch v2、C:\cfn\log で cfn ログを表示します。

    また、CloudFormation テンプレートを設定して、ログが Amazon CloudWatch に発行されるようにすることも可能です。Amazon CloudWatch はAWS Management Consoleにログを表示するため、Amazon EC2 インスタンスに接続する必要がなくなります。詳細については、アプリケーション管理ブログの View CloudFormation logs in the console を参照してください。

エラーのトラブルシューティング

CloudFormation スタックで以下のエラーが発生した場合は、問題の原因を特定して修正するために役立つ以下の解決策を使用できます。

スタックの削除の失敗

この状況を解決するには、以下の手順を実行します。

  • 一部のリソースは、削除する前に空にしなければなりません。たとえば、バケットまたはセキュリティグループを削除するには、Amazon S3 バケットのすべてのオブジェクト、または Amazon EC2 セキュリティグループのすべてのインスタンスを削除する必要があります。

  • スタックのリソースを削除するのに必要な IAM アクセス権限があることを確認します。CloudFormation 許可に加えて、Amazon S3 や Amazon EC2 などの基盤となるサービスを使用するための許可も必要です。

  • CloudFormation がリソースを削除できなかったことからスタックが DELETE_FAILED 状態になった場合は、RetainResources パラメータを使用し、CloudFormation が削除できないリソースを指定することで、削除を再度実行します。CloudFormation はスタックを削除しますが、保持されたリソースは削除しません。残したいオブジェクトを含む S3 バケットなど、リソースは削除できないが、スタックは削除したい場合に便利です。

    スタックを削除した後で、リソースに関連した AWS サービスを使用して、残したリソースを手動で削除できます。

    あるいは、DeletionMode パラメータを含む FORCE_DELETE_STACK オプションを使用することを検討することもできます。スタックを強制削除する方法の詳細については、「CloudFormation コンソールからスタックを削除する」を参照してください。

  • 削除保護を有効にしているスタックを削除することはできません。削除保護を有効にした状態でスタックを削除しようとすると、削除は失敗し、ステータスを含め、スタックが変更されることはありません。スタックの削除保護を無効にし、削除オペレーションを再度行います。

    これには、ルートスタックの削除保護が有効になっている「ネストされたスタック」が含まれます。ルートスタックの削除保護を無効にし、削除オペレーションを再度行います。ネストされたスタックは直接削除しないことが推奨されていますが、ルートスタックとそのリソースを削除する場合のみ削除します。

    詳細については、「CloudFormation スタックの削除を防止する」を参照してください。

  • AWS サポート がある場合は、その他すべての問題について、サポート ケースを作成できます。「 Support へのお問い合わせ」を参照してください。

依存関係のエラー

依存関係のエラーを解決するには、テンプレート内の他のリソースに依存するリソースに DependsOn 属性を追加します。場合によっては、CloudFormation が正しい順序でリソースを作成または削除できるように、依存関係を明示的に宣言する必要があります。たとえば、同じスタック内に Elastic IP およびインターネットゲートウェイを持つ VPC を作成する場合、Elastic IP はインターネットゲートウェイのアタッチメントに依存させる必要があります。詳細については、「DependsOn 属性」を参照してください。

AWS Config と AWS Systems Manager の競合

AWS Config と AWS Systems Manager はインフラストラクチャ管理タスクを自動化できますが、これが CloudFormation スタックのデプロイとの競合の原因になる場合があります。潜在的な競合を避けるため、以下を実行してください。

  • 関連付けられた AWS アカウントと AWS リージョンで、AWS Config と Systems Manager の設定を確認します。

  • CloudFormation のデプロイ中にトリガーされる可能性のあるアクティブなルールやオートメーションドキュメントをチェックします。これらは、競合、またはデプロイと競合するリソースの依存関係の原因になる可能性があります。

  • CloudFormation テンプレートで、AWS Config と Systems Manager が管理するリソースをチェックします。潜在的な重複や相互依存関係をチェックして、競合を避けるためにテンプレートまたはオートメーション設定を調整することを検討してください。

  • CloudFormation のデプロイ中は、関連する AWS Config ルールや Systems Manager のオートメーションを一時的に無効化または停止します。望ましいレベルのオートメーションとコンプライアンスを維持するため、デプロイが正常に行われた後は元の設定に戻すことを忘れないでください。

  • CloudFormation のログとエラーメッセージに AWS Config および Systems Manager に関連する問題への参照がないかどうかを確認し、競合の原因の特定に役立てます。

AWS Config ルールの詳細については、「Evaluating Resources with AWS Config ルール」を参照してください。

Systems Manager のオートメーションの詳細については、「AWS Systems Manager Automation」を参照してください。

リストを渡す際のパラメーター解析エラー

AWS CLI または CloudFormation を使用してリストを渡すときは、各カンマの前にエスケープ文字 (\) を追加します。次の例は、AWS CLI を使用する場合に入力パラメータを指定する方法を示しています。

ParameterKey=CIDR,ParameterValue='10.10.0.0/16\,10.10.0.0/24\,10.10.1.0/24'

IAM アクセス権限の不足

CloudFormation スタックを使用するときは、CloudFormation を使用する許可だけでなく、テンプレートに記述されている基盤となるサービスを使用する許可も必要になります。たとえば、Amazon S3 バケットを作成する場合や、Amazon EC2 インスタンスを開始する場合には、Amazon S3 または Amazon EC2 に対するアクセス権限が必要となります。CloudFormation スタックを使用する前に、IAM ポリシーを見直して、必要な許可があることを確認します。詳細については、「AWS Identity and Access Management で CloudFormation アクセスを制御する」を参照してください。

値が無効またはリソースのプロパティがサポートされていない

CloudFormation スタックを作成または更新するときは、無効な入力パラメータ、サポートされないリソースプロパティ名、またはサポートされないリソースプロパティ値が原因で、スタックが失敗する場合があります。入力パラメーターについては、そのリソースが存在することを確認します。たとえば、Amazon EC2 キーペアまたは VPC ID を指定する場合、リソースはアカウント内およびスタックを作成/更新しているリージョンに存在している必要があります。確実に有効な値を使用するには、AWS 固有のパラメータ型を使用できます。

リソースのプロパティ名と値については、テンプレートを更新して有効な名前と値を使用するようにしてください。詳細については、「AWS リソースおよびプロパティタイプのリファレンス」を参照してください。

リソースクォータ

リソースクォータに達していないことを確認します。例えば、起動できる Amazon EC2 オンデマンドインスタンスのデフォルトの最大数は 5 です。アカウントクォータよりも多くの Amazon EC2 オンデマンドインスタンスを作成しようとすると、インスタンスの作成が失敗し、エラー Status=start_failed が返されます。サービスごとのデフォルト AWS クォータを表示するには、「AWS 全般のリファレンス」の「AWS サービスクォータ」を参照してください。

CloudFormation のクォータと調整戦略については、「CloudFormation クォータを理解する」を参照してください。

また、更新中にリソースが置き換えられた場合は、CloudFormation が古いリソースを削除する前に新しいリソースを作成します。このリソースの置換によってリソースクォータに達してしまい、更新が失敗する場合があります。過剰なリソースを削除するか、[quota increase] (クォータの増加) をリクエストすることができます。

ネストされたスタックは UPDATE_COMPLETE_CLEANUP_IN_PROGRESS、UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS または UPDATE_ROLLBACK_IN_PROGRESS 状態にあります。

ネストされたスタックがロールバックに失敗しました。ネストされたスタック間における潜在的なリソースの依存関係が原因で、CloudFormation は、ネストされたスタックのすべてが更新される、またはロールバックされるまで、ネストされたスタックのクリーンアップを開始しません。ネストされたスタックのロールバックが失敗した場合、CloudFormation は他のスタックの状態にかかわらず、すべてのオペレーションをキャンセルします。ネストされたスタックで、更新またはロールバックを完了したが、別のネストされたスタックがロールバックに失敗したために CloudFormation からクリーンアップを開始するシグナルをから受け取らなかったというスタックは、UPDATE_COMPLETE_CLEANUP_IN_PROGRESS または UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS 状態になります。アップデートに失敗してもロールバックを開始する信号が届かないネストスタックは、UPDATE_ROLLBACK_IN_PROGRESS の状態になります。

ネストされたスタックは、スタックテンプレートがスタックの状態を正確に反映しないときに、CloudFormation 外で行われた変更が原因でロールバックに失敗する場合があります。また、Auto Scaling グループが作成またはアップデートされた際に、このグループのネストスタックに限定時間内のリソースが不足していると、ネストされたスタックが失敗することもあります。

スタックを修正するには、AWS サポート に連絡してください。

実行する更新がない

CloudFormation スタックを更新するには、テンプレートまたはパラメータの値の変更を CloudFormation に送信する必要があります。ただし、CloudFormation は一部のテンプレート変更を更新として認識しません。これには、削除ポリシー、更新ポリシー、条件の宣言、または出力の宣言に対する変更などがあります。他の変更を行わずにこのような変更を加える必要がある場合は、リソースの メタデータ属性を追加または変更します。CloudFormation はメタデータ属性のコンテンツを解釈しないため、この属性は任意の値にすることができます。詳細については、「Metadata 属性」を参照してください。

スタックの作成、更新、または削除オペレーションの際、リソースが安定しない

オペレーションが CloudFormation のタイムアウト時間を超過したか、AWS サービスが中断されたため、リソースが応答しませんでした。サービス中断の場合は、関連する AWS サービスが実行中であることを確認し、次にスタックオペレーションを再試行します。

AWS サービスが正常に実行中であれば、スタックに以下のリソースの 1 つが含まれているかどうかを確認してください。

  • AWS::AutoScaling::AutoScalingGroup 作成、更新、削除オペレーション

  • AWS::CertificateManager::Certificate 作成オペレーション

  • AWS::CloudFormation::Stack 作成、更新、削除オペレーション

  • AWS::ElasticSearch::Domain 更新オペレーション

  • AWS::RDS::DBCluster 作成および更新オペレーション

  • AWS::RDS::DBInstance 作成、更新、削除オペレーション

  • AWS::Redshift::Cluster 更新オペレーション

これらのリソースのオペレーションは、デフォルトのタイムアウト期間以上の時間がかかる場合があります。タイムアウト期間は、リソースと使用する認証情報によって異なります。タイムアウト期間を延長するには、スタックオペレーションを実行する際にサービスロールを指定します。すでにサービスロールを使用しているか、またはスタックにリストにないリソースが含まれている場合、AWS サポート にお問い合わせください。

スタックが UPDATE_ROLLBACK_FAILED という状態の場合、「更新のロールバックの失敗」を参照してください。

セキュリティグループが VPC 内に存在しない

セキュリティグループが指定した VPC に存在していることを確認します。セキュリティグループが存在する場合、セキュリティグループの名前ではなく、セキュリティグループの ID を指定していることを確認します。たとえば、AWS::EC2::SecurityGroupIngress リソースには、SourceSecurityGroupName プロパティと SourceSecurityGroupId プロパティがあります。VPC セキュリティグループについては、SourceSecurityGroupId を使用し、プロパティとセキュリティグループ ID を指定する必要があります。

更新のロールバックの失敗

ロールバックが失敗するため (UPDATE_ROLLBACK_FAILED 状態)、依存リソースを元の状態に戻すことはできません。例えば、CloudFormation 外で削除された古いデータベースインスタンスにロールバックするスタックがある場合などです。CloudFormation はデータベースが削除されたことを認識しておらず、データベースインスタンスがまだ存在していると想定し、それにロールバックしようとすることから、更新のロールバックが失敗します。

失敗の原因によっては、エラーを手動で修正してロールバックを続けることができます。ロールバックを続けることで、スタックを動作状態 (UPDATE_ROLLBACK_COMPLETE 状態) に戻し、スタックの更新を再度試みることができます。次のリストでは、更新のロールバック失敗の原因となる一般的なエラーに対する解決策について説明します。

  • 必要なシグナルの数の受け取りに失敗した

    signal-resource コマンドを使用し、必要な数の成功シグナルを待機中のリソースに手動で送信した後、更新のロールバックを続けます。たとえば、更新のロールバック中、Auto Scaling グループ内のインスタンスが指定されたタイムアウト期間内に成功のシグナルの送信に失敗する可能性があります。Auto Scaling グループに成功シグナルを手動で送信します。更新のロールバックを続行すると、CloudFormation がシグナルを認識し、ロールバックを続行します。

  • リソースに対する変更が CloudFormation 外で行われた

    元のスタックテンプレートと一致するようにリソースを手動で同期した後、更新のロールバックを続けます。例えば、CloudFormation がロールバックしようとしているリソースを手動で削除した場合は、元のスタックで設定されていたものと同じ名前とプロパティを使用して、そのリソースを手動で作成する必要があります。

  • アクセス権限の不足

    リソースを変更する IAM アクセス権限が十分にあることを確認し、更新のロールバックを続けます。たとえば、IAM ポリシーで S3 バケットの作成が許可されるが、バケットの変更は許可されないことがあります。ポリシーに変更アクションを追加します。

  • 無効なセキュリティトークン

    CloudFormation には、新しい認証情報セットが必要です。変更は必要ありません。更新のロールバックを続けると、認証情報が更新されます。

  • 制限エラー

    不要なリソースを削除するか、[quota increase] (クォータの増加) をリクエストし、更新のロールバックを続けます。例えば、EC2 オンデマンドインスタンス数のアカウントクォータが 5 で、更新のロールバックがそのクォータを超えた場合、失敗します。

  • リソースが安定しませんでした

    オペレーションが CloudFormation のタイムアウト時間を超過したか、AWS サービスが中断された可能性があるため、リソースが応答しませんでした。変更は必要ありません。リソース操作が完了するか、AWS サービスが実行状態に戻ったら、更新のロールバックを続けてください。

更新のロールバックを続行するには、CloudFormation コンソール、または AWS コマンドラインインターフェース (AWS CLI) を使用できます。詳細については、「更新のロールバックを続ける」を参照してください。

これらのどの解決策を使用しても問題が解決されない場合は、CloudFormation が正常にロールバックできないリソースをスキップすることができます。詳細については、「AWS CloudFormation API Reference」で ContinueUpdateRollback APIオペレーション用の ResourcesToSkip パラメータを参照してください。CloudFormation は指定されたリソースのステータスを UPDATE_COMPLETE に設定し、引き続きスタックをロールバックします。ロールバックが完了したら、スキップされたリソースのステータスはスタックテンプレートのリソースのステータスと一致しません。別のスタックの更新を実行する前に、リソースを変更するか、またはスタックを更新して、整合性を取る必要があります。そうしないと、以降のスタックの更新は失敗し、スタックは回復不可能になる可能性があります。

待機条件が Amazon EC2 インスタンスから所定の数のシグナルを受け取らなかった

この状況を解決するには、以下の手順を実行します。

  • 使用している AMI に CloudFormation ヘルパースクリプトがインストールされていることを確認します。AMI にヘルパースクリプトが含まれていない場合は、インスタンスにダウンロードすることもできます。詳細については、 の「CloudFormation ヘルパースクリプトリファレンス」を参照してください。

  • インスタンスで cfn-signal コマンドが正常に実行されたことを確認します。/var/log/cloud-init.log や /var/log/cfn-init.log などのログを確認して、インスタンスの起動に関するデバッグに役立てることができます。ログはインスタンスにログインすることで取得できますが、これには失敗時のロールバックを無効化しておく必要があります。無効化されていないと、スタックの作成失敗後に CloudFormation がインスタンスを削除します。また、Amazon CloudWatch に対してログを発行することもできます。Windows の場合、C:\cfn\log および %ProgramFiles%\Amazon\EC2ConfigService に保存される cfn ログを確認できます。

  • インスタンスがインターネットに接続されていることを確認します。インスタンスが VPC 内に存在しており、プライベートサブネットにある場合は NAT デバイスを介して、パブリックサブネットにある場合はインターネットゲートウェイを介してインターネットに接続されます。インスタンスのインターネット接続をテストするには、http://aws.amazon.com などの公開ウェブページへアクセスしてください。たとえば、インスタンスで次のコマンドを実行すると、HTTP 200 ステータスコードが返されるはずです。

    curl -I https://aws.amazon.com

    NAT デバイスの設定の詳細については、「Amazon VPC ユーザーガイド」の「NAT」を参照してください。

リソースはスタックから削除されましたが、削除されてはいません。

スタックの更新中に、CloudFormation はスタックからリソースを削除しましたが、リソースは削除されませんでした。リソースはまだ存在しますが、CloudFormation からはアクセスできなくなります。これは、スタックの更新中に発生する可能性があります。

  • CloudFormation は既存のリソースを置き換える必要があるため、最初に新しいリソースを作成し、次に古いリソースを削除しようとします。

  • スタックテンプレートからリソースを削除したため、CloudFormation はスタックからリソースを削除しようとします。

ただし、CloudFormation がリソースを削除できない場合があります。例えば、特定のタイプのリソースを削除するためのアクセス権限がユーザーにない場合などです。

CloudFormation は、古いリソースを 3 回削除しようとします。CloudFormation が古いリソースを削除できない場合、古いリソースをスタックから削除し、スタックの更新を続行します。スタックの更新が完了すると、CloudFormation は UPDATE_COMPLETE スタックイベントを発行しますが、1 つ以上のリソースを削除できなかったことを示す StatusReason が含まれます。CloudFormation は、特定のリソースに対して DELETE_FAILED イベントを発行し、対応する StatusReason は CloudFormation がリソースの削除に失敗した理由の詳細を提供します。

この状況を解決するには、基盤となるサービスのコンソールまたは API を使用してリソースを直接削除します。

Support へのお問い合わせ

AWS サポート がある場合は、https://console.aws.amazon.com/support/home#/ で技術サポートケースを作成できます。サポートへ連絡する前に、以下の情報を収集します。

  • スタックの ID。スタック ID は、CloudFormation コンソールの [概要] タブにあります。詳細については、「CloudFormation コンソールからスタック情報を表示する」を参照してください。

    重要

    CloudFormation 外でスタックを変更しないでください。CloudFormation 外でスタックを変更すると、スタックが復旧不可能な状態になる場合があります。

  • スタックのエラーメッセージ。スタックのエラーメッセージの表示については、「トラブルシューティングガイド」セクションを参照してください。

  • Amazon EC2 の問題については、cloud-init および cfn のログを収集してください。これらのログは、/var/log/ ディレクトリの Amazon EC2 インスタンスに発行されます。これらのログには、インスタンスのセットアップ中のプロセスおよびコマンドの出力がキャプチャされます。Windows の場合、%ProgramFiles%\Amazon\EC2ConfigService および C:\cfn\log に保存される EC2Configure サービスおよび cfn ログを収集してください。

また、AWS re:Post の CloudFormation コミュニティで答えを探したり、質問を投稿したりすることもできます。