• AWS Systems Manager CloudWatch ダッシュボードは、2026 年 4 月 30 日以降は利用できなくなります。お客様は、これまでと同様に Amazon CloudWatch コンソールを使用して、Amazon CloudWatch ダッシュボードの表示、作成、管理を継続できます。詳細については、「[Amazon CloudWatch ダッシュボードのドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)」を参照してください。 # メンテナンスウィンドウのトラブルシューティング 以下の情報を参考にして、メンテナンスウィンドウに関する問題のトラブルシューティングを行います。 **Topics** + [ ## タスクの編集エラー: メンテナンスウィンドウのタスクを編集するためのページで、IAM ロールリストから次のエラーメッセージが返されます。「このタスクに指定されている IAM メンテナンスウィンドウのロールが見つかりませんでした。このロールは削除された可能性があるか、まだ作成されていない可能性があることを示すエラーメッセージを返す ](#maintenance-window-role-troubleshooting) + [ ## すべてのメンテナンスウィンドウのターゲットが更新されるわけではありません。 ](#targets-not-updated) + [ ## タスクがタスク呼び出しステータスで失敗する:「The provided role does not contain the correct SSM permissions.」(指定されたロールには正しい SSM 許可が含まれていません。) ](#incorrect-ssm-permissions) + [ ## タスクはエラーメッセージで失敗します:「Step fails when it is validating and resolving the step inputs」 ](#step-fails) + [ ## エラーメッセージ:「Maintenance window tasks without targets don't support MaxConcurrency values」および「Maintenance window tasks without targets don't support MaxErrors values」 ](#maxconcurrency-maxerrors-not-supported) ## タスクの編集エラー: メンテナンスウィンドウのタスクを編集するためのページで、IAM ロールリストから次のエラーメッセージが返されます。「このタスクに指定されている IAM メンテナンスウィンドウのロールが見つかりませんでした。このロールは削除された可能性があるか、まだ作成されていない可能性があることを示すエラーメッセージを返す **問題 1**: タスクを作成したら、元々指定していたAWS Identity and Access Management （IAM) メンテナンスウィンドウロールが削除された。 **解決方法**: 1) 別の IAM メンテナンスウィンドウロールを選択する。(アカウントに存在する場合)、新しいロールを作成してそのタスク用に選択します。 **問題 2**: AWS Command Line Interface (AWS CLI)、AWS Tools for Windows PowerShell、または AWS SDK を使用してタスクが作成された場合は、存在しない IAM メンテナンスウィンドウロールの名前が指定された可能性があります。例えば、タスクを作成する前に IAM メンテナンスウィンドウロールが削除された、またはロール名が正しく入力されなかった可能性があります (例えば、**myrole** ではなく **my-role** と入力した)。 **解決方法**: 使用する IAM メンテナンスウィンドウロールの正しい名前を選択するか、新しいロールを作成してそのタスク用に指定します。 ## すべてのメンテナンスウィンドウのターゲットが更新されるわけではありません。 **問題:** メンテナンスウィンドウのタスクが、メンテナンスウィンドウの対象となるすべてのリソースで実行されなかったことに気付きました。たとえば、メンテナンスウィンドウの実行結果で、そのリソースのタスクが失敗またはタイムアウトとしてマークされます。 **解決方法:** メンテナンスウィンドウタスクがターゲットリソースで実行されない最も一般的な理由は、接続性と可用性です。以下に例を示します。 + Systems Manager メンテナンスウィンドウの操作前または操作中にリソースへの接続が失われました。 + リソースがオフラインだったか、メンテナンスウィンドウの操作中に停止しました。 リソースでタスクを実行するために、次のスケジュールされたメンテナンスウィンドウ時間を待つことができます。使用できないリソースまたはオフラインだったリソースに対して、メンテナンスウィンドウタスクを手動で実行できます。 ## タスクがタスク呼び出しステータスで失敗する:「The provided role does not contain the correct SSM permissions.」(指定されたロールには正しい SSM 許可が含まれていません。) **問題**: タスクにメンテナンスウィンドウサービスロールを指定しましたが、タスクが正常に実行されず、タスク呼び出しステータスが「"The provided role does not contain the correct SSM permissions.」(指定されたロールには正しい SSM 許可が含まれていません) とレポートします。 + **解決策**: [タスク 1: コンソールを使用して、メンテナンスウィンドウサービスロール用にカスタムポリシーを作成する](configuring-maintenance-window-permissions-console.md#create-custom-policy-console) では、[カスタムメンテナンスウィンドウのサービスロール](configuring-maintenance-window-permissions-console.md#create-custom-role-console)にアタッチできる基本ポリシーを提供しています。ポリシーには、多くのタスクシナリオに必要な許可が含まれています。ただし、実行できるタスクは多種多様であるため、メンテナンスウィンドウロールのポリシーで追加の許可を提供する必要がある場合があります。 たとえば、一部のオートメーションアクションは AWS CloudFormation スタックと連携します。したがって、メンテナンスウィンドウサービスロールのポリシーに、追加の許可 `cloudformation:CreateStack`、`cloudformation:DescribeStacks`、`cloudformation:DeleteStack` を追加する必要がある場合があります。 別の例: オートメーションランブックの `AWS-CopySnapshot` では、Amazon Elastic Block Store (Amazon EBS) スナップショットを作成するためのアクセス許可が必要です。したがって、許可 `ec2:CreateSnapshot` を追加する必要がある場合があります。 AWS マネージド自動化ランブックに必要なロール許可については、「[AWS Systems Manager 自動化ランブックリファレンス](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html)」のランブックの説明を参照してください。 AWS マネージド SSM ドキュメントが必要とするロールの許可については、Systems Manager コンソールの「[ドキュメント](https://console.aws.amazon.com//systems-manager/documents)」セクションでドキュメントの内容を確認してください。 Step Functions タスク、Lambda タスク、カスタム Automation ランブックおよび SSM ドキュメントに必要なロール許可については、それらのリソースの作成者に許可要件を確認してください。 ## タスクはエラーメッセージで失敗します:「Step fails when it is validating and resolving the step inputs」 **問題**: タスクで使用しているオートメーションランブックまたは Systems Manager Command ドキュメントでは `InstanceId` や `SnapshotId` などの入力を指定する必要がありますが、値が指定されていないか、正しく指定されていません。 + **解決策 1 **: タスクが 1 つのリソース (単一ノードやスナップショットなど) を対象とする場合は、タスクの入力パラメーターにその ID を入力します。 + **解決策 2**: タスクが複数のリソースをターゲットにしている場合 (ランブック `AWS-CreateImage` を使用するときに複数のノードからイメージを作成する場合など)、メンテナンスウィンドウタスクでサポートされている擬似パラメータの 1 つを入力パラメータで使用して、コマンドでノード ID を表すことができます。 以下のコマンドは、AWS CLI を使用して、Systems Manager Automation タスクをメンテナンスウィンドウに登録します。`--targets` の値は、メンテナンスウィンドウのターゲット ID を示します。また、`--targets` パラメータでウィンドウターゲット ID が指定されていても、Automation ランブックのパラメータにはノード ID を指定する必要があります。この場合、コマンドは擬似パラメーター`{{RESOURCE_ID}}` を `InstanceId` の値として使用します。 ** AWS CLI コマンド:** ------ #### [ Linux & macOS ] 次のサンプルコマンドは、メンテナンスウィンドウのターゲットグループに属する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを ID e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE で再起動します。 ``` aws ssm register-task-with-maintenance-window \ --window-id "mw-0c50858d01EXAMPLE" \ --targets Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE \ --task-arn "AWS-RestartEC2Instance" \ --service-role-arn arn:aws:iam::123456789012:role/MyMaintenanceWindowServiceRole \ --task-type AUTOMATION \ --task-invocation-parameters "Automation={DocumentVersion=5,Parameters={InstanceId='{{RESOURCE_ID}}'}}" \ --priority 0 --max-concurrency 10 --max-errors 5 --name "My-Restart-EC2-Instances-Automation-Task" \ --description "Automation task to restart EC2 instances" ``` ------ #### [ Windows ] ``` aws ssm register-task-with-maintenance-window ^ --window-id "mw-0c50858d01EXAMPLE" ^ --targets Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE ^ --task-arn "AWS-RestartEC2Instance" ^ --service-role-arn arn:aws:iam::123456789012:role/MyMaintenanceWindowServiceRole ^ --task-type AUTOMATION ^ --task-invocation-parameters "Automation={DocumentVersion=5,Parameters={InstanceId='{{RESOURCE_ID}}'}}" ^ --priority 0 --max-concurrency 10 --max-errors 5 --name "My-Restart-EC2-Instances-Automation-Task" ^ --description "Automation task to restart EC2 instances" ``` ------ メンテナンスウィンドウタスクの擬似パラメータの使用の詳細については、[メンテナンスウィンドウのタスクを登録する際の疑似パラメータの使用](maintenance-window-tasks-pseudo-parameters.md) および [タスクの登録例](mw-cli-register-tasks-examples.md#task-examples) を参照してください。 ## エラーメッセージ:「Maintenance window tasks without targets don't support MaxConcurrency values」および「Maintenance window tasks without targets don't support MaxErrors values」 **問題:** Run Command タイプタスクを登録するときは、タスクを実行するターゲットを少なくとも 1 つ指定する必要があります。他のタスクタイプ (自動化、AWS Lambda、および AWS Step Functions) では、タスクの特質に応じて、ターゲットはオプションです。ターゲットを指定しないメンテナンスウィンドウタスクでは、オプション `MaxConcurrency` (同時にタスクを実行するリソースの数) と `MaxErrors` (タスクが失敗するまでにターゲットリソースでタスクの実行が失敗できる数) は必須ではなく、サポートされていません。タスクターゲットが指定されていない場合、これらのオプションのいずれかに値が指定されると、システムはこのようなエラーメッセージを生成します。 **解決方法**: これらのエラーのいずれかを受け取った場合は、メンテナンスウィンドウタスクの登録または更新を続行する前に、同時実行性とエラーしきい値の値を削除します。 ターゲットを指定しないタスクの実行の詳細については、*AWS Systems Manager ユーザーガイド*の「[ターゲットのないメンテナンスウィンドウタスクを登録](maintenance-windows-targetless-tasks.md)」を参照してください 。