翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AMS Accelerate でのモニタリングとイベント管理 AMS Accelerate モニタリングシステムは、障害、パフォーマンスの低下、セキュリティの問題がないか AWS リソースをモニタリングします。 マネージドアカウントとして、AMS Accelerate は該当する AWS リソースのアラームを設定およびデプロイし、これらのリソースをモニタリングして、必要に応じて修復を実行します。 AMS Accelerate モニタリングシステムは、Resource Tagger や Alarm Manager などの内部ツールに依存し、 AWS のサービス、、Amazon CloudWatch (CloudWatch)[AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)、Amazon EventBridge (旧称 CloudWatch)、Amazon GuardDuty、Amazon Macie、 などの を活用します AWS Health。 AMS Accelerate は、運用上の優秀性の実現に役立つさまざまな運用サービスを提供します AWS。24 時間 365 日体制のヘルプデスク、プロアクティブモニタリング、セキュリティ、パッチ適用、ログ記録、バックアップなど、いくつかの主要な運用機能 AWS クラウド を使用して、AMS が で全体的な運用上の優秀性を達成するのに役立つ方法をすばやく理解するには、[「AMS リファレンスアーキテクチャ図](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/AWS-managed-services-for-operational-excellence-ra.pdf)」を参照してください。 **Topics** + [モニタリングとは](#what-is-monitoring) + [モニタリングの仕組み](how-monitoring-works.md) + [AMS でのベースラインモニタリングからのアラート](monitoring-default-metrics.md) + [AMS でのアプリケーション対応インシデント通知](app-aware-inc-notifications.md) + [アラームマネージャーの高速化](acc-mem-tag-alarms.md) + [アラートの AMS 自動修復](auto-remediation.md) + [AMS での Amazon EventBridge マネージドルールの使用](how-event-router-works.md) + [AMS の信頼された修復](trusted-remediator.md) Amazon EKS のモニタリングについては、「」を参照してください。 [AMS Accelerate での Amazon EKS のモニタリングとインシデント管理](acc-mon-inc-mgmt-eks.md) ## モニタリングとは AMS Accelerate モニタリングには以下の利点があります。 + 選択したすべての またはサポートされている AWS リソースについて、マネージドアカウント全体でポリシーを作成、管理、デプロイするデフォルト設定。 + マネージドアカウントに対して他のモニタリングを設定していない場合でも、デフォルトの保護レベルを持つモニタリングベースライン。詳細については、「[AMS でのベースラインモニタリングからのアラート](monitoring-default-metrics.md)」を参照してください。 + 要件を満たすようにベースラインリソースアラームをカスタマイズする機能。 + アプリケーションへの影響を防止または軽減するために、可能な場合は AMS オペレーションによるアラートの自動修復。たとえば、スタンドアロンの Amazon EC2 インスタンスを使用していて、システムヘルスチェックに失敗した場合、AMS はインスタンスを停止して再起動することでインスタンスの復旧を試みます。詳細については、「[アラートの AMS 自動修復](auto-remediation.md)」を参照してください。 + OpsCenter を使用して、アクティブで以前に解決されたアラートを可視化します。例えば、Amazon EC2 インスタンスで予期しない CPU 使用率が高い場合、 AWS Systems Manager コンソールへのアクセス (OpsCenter コンソールへのアクセスを含む) をリクエストし、OpsCenter コンソールで OpsItem を直接表示できます。 OpsCenter + アラートを調査して、適切なアクションを決定します。詳細については、「[AMS Accelerate でのインシデント管理](acc-manage-incidents.md)」を参照してください。 + アカウントの設定とサポートされている AWS サービスに基づいて生成されたアラート。アカウントのモニタリング設定は、アラートを作成するアカウント内のすべてのリソースパラメータを指します。アカウントのモニタリング設定には、CloudWatch アラーム定義と、アラート (アラームまたはイベント) を生成する EventBridge (旧 CloudWatch Events) が含まれます。リソースパラメータの詳細については、「」を参照してください[AMS でのベースラインモニタリングからのアラート](monitoring-default-metrics.md)。 + 差し迫った障害、継続的障害、後退障害、潜在的な障害、パフォーマンスの低下、またはアカウントで設定されたベースラインモニタリングによって生成されたセキュリティ問題 (アラートと呼ばれる) の通知。アラートの例には、CloudWatch アラーム、イベント、GuardDuty や などの AWS サービスからの検出結果などがあります AWS Health。 # モニタリングの仕組み AWS Managed Services (AMS) のモニタリングアーキテクチャについては、次の図を参照してください。 次の図は、**AMS Accelerate** のモニタリングアーキテクチャを示しています。 ![\[AMS モニタリングアーキテクチャ。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/accelerate-guide/images/monitoringNew2.png) リソースが Resource Tagger を使用して定義されたポリシーに基づいてタグ付けされ、アラーム定義がデプロイされた後、次のリストで AMS モニタリングプロセスについて説明します。 + 生成: アカウントのオンボーディング時に、AMS はマネージドアカウントで作成されたすべてのリソースのベースラインモニタリング (CloudWatch (CW) アラームと CW イベントルールの組み合わせ) を設定します。ベースラインモニタリング設定は、CW アラームがトリガーされたとき、または CW イベントが生成されたときにアラートを生成します。 + 集約: リソースによって生成されたすべてのアラートは、アカウントの SNS トピックに誘導することで AMS モニタリングシステムに送信されます。AMS が Amazon EC2 アラートをグループ化する方法を設定することもできます。AMS は、同じ EC2 インスタンスに関連するすべてのアラートを 1 つのインシデントにグループ化するか、必要に応じてアラートごとに 1 つのインシデントを作成します。この設定は、Cloud Service Delivery Manager または Cloud Architect を使用していつでも変更できます。 + 処理: AMS はアラートを分析し、影響の可能性に基づいてアラートを処理します。アラートは次に示すように処理されます。 + 既知の顧客への影響があるアラート: 新しいインシデントレポートが作成され、AMS はインシデント管理プロセスに従います。 アラートの例: Amazon EC2 インスタンスはシステムヘルスチェックに失敗し、AMS はインスタンスを停止して再起動することでインスタンスの復旧を試みます。 + 顧客への影響が不明なアラート: これらのタイプのアラートの場合、AMS はインシデントレポートを送信します。多くの場合、AMS がアクションを実行する前に影響を検証するように求められます。ただし、インフラストラクチャ関連のチェックに合格した場合、AMS はインシデントレポートを送信しません。 例: Amazon EC2 インスタンスでの 10 分以上の >85% CPU 使用率のアラートは、この動作が使用状況に基づいて予想される可能性があるため、すぐにインシデントとして分類することはできません。この例では、AMS Automation はリソースに対してインフラストラクチャ関連のチェックを実行します。これらのチェックに合格した場合、CPU 使用率が 99% を超えた場合でも、AMS はアラート通知を送信しません。インフラストラクチャ関連のチェックがリソースで失敗していることをオートメーションが検出した場合、AMS はアラート通知を送信し、緩和が必要かどうかを確認します。アラート通知については、このセクションで詳しく説明します。AMS は、通知で緩和オプションを提供します。アラートがインシデントであることを確認する通知に返信すると、AMS は新しいインシデントレポートを作成し、AMS インシデント管理プロセスが開始されます。「顧客への影響なし」または 3 日間応答なしの応答を受信するサービス通知は、解決済みとしてマークされ、対応するアラートは解決済みとしてマークされます。 + 顧客への影響がないアラート: 評価後、AMS がアラートに顧客への影響がないと判断した場合、アラートはクローズされます。 たとえば、 は置き換えが必要な EC2 インスタンス AWS Health を通知しますが、そのインスタンスはその後終了しています。 ## EC2 インスタンスグループ化通知 同じ EC2 インスタンスからのアラートを 1 つのインシデントにグループ化するように AMS モニタリングを設定できます。Cloud Service Delivery Manager または Cloud Architect がこれを設定できます。AMS 管理アカウントごとに設定できるパラメータは 4 つあります。 1. **スコープ**: **アカウント全体**または**タグベース**のいずれかを選択します。 + そのアカウントのすべての EC2 インスタンスに適用される設定を指定するには、スコープ = **アカウント全体**を選択します。 + 特定のタグを持つそのアカウントの EC2 インスタンスにのみ適用される設定を指定するには、スコープ = **タグベース**を選択します。 1. **グループ化ルール**: **クラシック**または**インスタンス**を選択します。 + アカウント内のすべてのリソースに対してインスタンスレベルのグループ化を設定するには、スコープ = **アカウント全体**、グループ化ルール = **インスタンス**を選択します。 + インスタンスレベルのグループ化を使用するようにアカウント内の特定のリソースを設定するには、それらのインスタンスにタグを付け、スコープ = **タグベース**、グループ化ルール = **インスタンス**レベルを選択します。 + アカウントのアラートにインスタンスグループ化を使用しないには、グループ化ルール = **クラシック**を選択します。 1. **エンゲージメント**オプション: **なし**、**レポートのみ**、または**デフォルト**のいずれかを選択します。 + 設定がアクティブな間、AMS がインシデントを作成したり、それらのリソースからアラームのオートメーションを実行したりしない場合は、**なし**を選択します。 + 設定のアクティブ中に AMS がインシデントを作成したり、それらのリソースからアラームの自動化を実行したりせず、自動ヒーリング Systems Manager ドキュメントを実行したりせず、これらのイベントのレコードをレポートに含めるには、**レポートのみ**を選択します。これは、やり取りするインシデントサポートケースの量を減らしたい場合や、非本番稼働用アカウントのインシデントなど、一部のリソースからのインシデントに即時の対応が必要ない場合に便利です。 + AMS がアラートを処理し、オートメーションを実行し、必要に応じてインシデントケースを作成するには、**デフォルト**を選択します。 1. **解決後: ****24 時間**、**48 時間**、または **72 時間**のいずれかを選択します。最後に、インシデントケースが自動的にクローズされるタイミングを設定します。最後のケースコレスポンデンスからの時間が、設定された**解決後**値に達すると、インシデントはクローズされます。 ### アラート通知 アラート処理の一環として、AWS AWS Managed Services (AMS) は影響分析に基づいてインシデントを作成し、影響を特定できる場合に、修復のためのインシデント管理プロセスを開始します。影響が判断できない場合、AMS はサービス通知を通じてアカウントに関連付けられた E メールアドレスにアラート通知を送信します。一部のシナリオでは、このアラート通知は送信されません。たとえば、インフラストラクチャ関連のチェックが CPU 使用率の高いアラートを渡す場合、アラート通知は送信されません。詳細については、 のアラート処理プロセスの AMS モニタリングアーキテクチャの図を参照してください[モニタリングの仕組み](#how-monitoring-works)。 ## タグベースのアラート通知 タグを使用して、リソースのアラート通知をさまざまな E メールアドレスに送信します。1 つの E メールアドレスに送信される通知は、複数のデベロッパーチームが同じアカウントを使用する場合に混乱を引き起こす可能性があるため、タグベースのアラート通知を使用するのがベストプラクティスです。タグベースのアラート通知は、選択した[EC2 インスタンスグループ化通知](#how-monitoring-works-alert-notes-grouping)設定の影響を受けません。 タグベースのアラート通知を使用すると、次のことができます。 + **特定の E メールアドレスにアラートを送信する**: `key = OwnerTeamEmail`、 を使用して、特定の E メールアドレスに送信する必要があるアラートを含むリソースにタグ付けします`value = EMAIL_ADDRESS`。 + **複数の E メールアドレスにアラートを送信する**: 複数の E メールアドレスを使用するには、値のカンマ区切りリストを指定します。例えば、`key = OwnerTeamEmail` や `value = EMAIL_ADDRESS_1, EMAIL_ADDRESS_2, EMAIL_ADDRESS_3, ...` などです。値フィールドの合計文字数は 260 を超えることはできません。 + **カスタムタグキー**を使用する: カスタムタグキーを使用するには、タグベースの通信の自動通知を有効にすることを明示的に同意する E メールで CSDM にカスタムタグキー名を指定します。すべてのインスタンスとリソースで問い合わせタグに同じタグ付け戦略を使用するのがベストプラクティスです。 **注記** *OwnerTeamEmail* のキー値はキャメルケースである必要はありません。ただし、タグでは大文字と小文字が区別されるため、推奨形式を使用することをお勧めします。 ローカル部分をドメインから分離するには、E メールアドレスを完全に指定し、「アットマーク」 (@) を指定する必要があります。無効な E メールアドレスの例: *Team.AppATabc.xyz* または *john.doe*。タグ付け戦略に関する一般的なガイダンスについては、「 [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)」を参照してください。タグに個人を特定できる情報 (PII) を追加しないでください。可能な限りディストリビューションリストまたはエイリアスを使用します。 タグベースのアラート通知は、次の Amazon サービスのリソースでサポートされています。EC2、Elastic Block Store (EBS)、Elastic Load Balancing (ELB)、Application Load Balancer (ALB)、Network Load Balancer、リレーショナルデータベースサービス (RDS)、OpenSearch、Elastic File System (EFS)、FSx、Site-to-Site VPN。 # AMS でのベースラインモニタリングからのアラート AMS Accelerate のモニタリングのデフォルトについて説明します。詳細については、「[AMS Accelerate でのモニタリングとイベント管理](acc-mon-event-mgmt.md)」を参照してください。 次の表は、モニタリング対象とデフォルトのアラートしきい値を示しています。アラートしきい値は、カスタム設定ドキュメントで変更することも、サービスリクエストを送信することもできます。カスタムアラーム設定を変更する手順については、「」を参照してください[Accelerate アラーム設定の変更](acc-mem-change-am.md)。アラームがしきい値を超えたときに通知を受け取るには、AMS の標準アラートプロセスに加えて、アラーム設定を上書きできます。手順については、「[アラームマネージャーの高速化](acc-mem-tag-alarms.md)」を参照してください。 Amazon CloudWatch は、メトリクスの保持期間を延長します。詳細については、[CloudWatch の制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html)」を参照してください。 **注記** AMS Accelerate は、ベースラインモニタリングを定期的にキャリブレーションします。新しいアカウントは常に最新のベースラインモニタリングでオンボーディングされ、表は新しくオンボーディングされたアカウントのベースラインモニタリングを示しています。AMS Accelerate は、既存のアカウントのベースラインモニタリングを定期的に更新し、更新が行われるまでに遅延が発生する場合があります。 **ベースラインモニタリングからのアラート** | サービス/リソースタイプ | アラートソースとトリガーの条件 | アラート名とメモ | | --- | --- | --- | | スター付き (**\$1**) アラートの場合、AMS は影響を事前に評価し、可能な場合は修復します。修復が不可能な場合は、AMS はインシデントを作成します。自動化によって問題が修正されない場合、AMS はインシデントケースを通知し、AMS エンジニアが対応します。さらに、Direct-Customer-Alerts SNS トピックにオプトインすると、これらのアラートは E メールに直接送信されます。 | | Application Load Balancer インスタンス | ApplicationLoadBalancerErrorCount (HTTPCode\$1ELB\$15XX\$1Count/RequestCount)\$1100 sum > 15% for 1 min, 5 consecutive times。 | Application LoadBalancer HTTP 5XX エラー数 Loadbalancer によって生成された過剰な数の HTTP 5XX レスポンスコードに対する CloudWatch アラーム。 | | Application Load Balancer インスタンス | RejectedConnectionCount sum > 0% for 1 min, 5 consecutive times。 | Application LoadBalancer が拒否した接続数 ロードバランサーが最大数に達したために拒否された接続の数がある場合の CloudWatch アラーム | | Application Load Balancer ターゲット | TargetConnectionErrorCount (HTTPCode\$1Target\$15XX\$1Count/RequestCount)\$1100 sum > 15% for 1 min, 5 consecutive times。 | \$1\$1ElasticLoadBalancingV2::TargetGroup::FullName\$1 - Application LoadBalancer ターゲット接続エラー数 - \$1\$1ElasticLoadBalancingV2::TargetGroup::UUID\$1 ターゲットによって生成された HTTP 5XX レスポンスコードの超過数に関する CloudWatch アラーム。 | | Application Load Balancer ターゲット | ApplicationLoadBalancerTargetGroupErrorCount sum > 0% for 1 min, 5 consecutive times。 | \$1\$1ElasticLoadBalancingV2::TargetGroup::FullName\$1 - Application LoadBalancer ターゲット HTTP 5XX エラー数 - \$1\$1ElasticLoadBalancingV2::TargetGroup::UUID\$1 ロードバランサーと登録されたインスタンス間の接続数が正常に確立されなかった場合の CloudWatch アラーム。 | | Amazon EC2 インスタンス - すべての OSs | CPUUtilization**\$1** > 5 分間 95%、連続 6 回。 | \$1\$1EC2::InstanceId\$1: CPU が高すぎる CloudWatch アラーム。CPU 使用率が高いことは、デッドロック、無限ループ、悪意のある攻撃、その他の異常など、アプリケーションの状態の変化を示す指標です。 これらは Direct-Customer-Alerts アラームです。 | | Amazon EC2 インスタンス - すべての OSs | StatusCheckFailed > 0%、5 分間、3 回連続。 | \$1\$1EC2::InstanceId\$1: ステータスチェックに失敗しました CloudWatch アラーム。ステータスチェック失敗 は、指定された ID を持つ Amazon EC2 インスタンスが 1 つ以上の自動ステータスチェックに失敗したことを示します。つまり、インスタンスが正しく動作したり、到達できない問題が発生しています。 | | Amazon EC2 インスタンス - Linux | 最小 mem\$1used\$1percent >= 5 分間 95%、連続 6 回。 | \$1\$1EC2::InstanceId\$1: メモリフリー CloudWatch アラーム。Memory Free は、指定された Amazon EC2 インスタンスで使用可能なメモリ (RAM) が定義されたしきい値を下回ったことを示します。これにより、メモリの問題、システムのクラッシュが発生し、インスタンスがより多くの RAM を必要とする可能性があることを示します。 これらは Direct-Customer-Alerts アラームです。 | | Amazon EC2 インスタンス - Linux | 平均 Swap\$1used\$1percent >= 5 分間 95%、連続 6 回。 | \$1\$1EC2::InstanceId\$1: スワップ無料 CloudWatch アラーム。Amazon EC2 インスタンスの平均 Swap\$1used\$1percent は、現在使用されている割り当てられたスワップ領域の平均割合が事前定義されたしきい値を超えていることを示します。これにより、パフォーマンスの低下、ボトルネック、メモリの問題が発生する可能性があります。 これらは Direct-Customer-Alerts アラームです。 | | Amazon EC2 インスタンス - Linux | 最大 disk\$1used\$1percent >= 5 分間 95%、連続 6 回。 | \$1\$1EC2::InstanceId\$1: ディスク使用率が高すぎる - \$1\$1EC2::Disk::UUID\$1 CloudWatch アラーム。ディスク使用率が高すぎるとは、特定の Amazon EC2 または識別されたディスクのディスク使用率が容量に近づいていることを示します。これにより、パフォーマンスの低下、アプリケーションエラー、システムの不安定性が発生する可能性があります。 これらは Direct-Customer-Alerts アラームです。 | | Amazon EC2 インスタンス - Windows | 使用中の最小メモリコミットバイト率 >= 5 分間 95%、連続 6 回。 | \$1\$1EC2::InstanceId\$1: メモリフリー CloudWatch アラーム。Memory Free は、指定された Amazon EC2 インスタンスで使用可能なメモリ (RAM) が定義されたしきい値を下回ったことを示します。これにより、メモリの問題、システムのクラッシュが発生し、インスタンスがより多くの RAM を必要とする可能性があることを示します。 これらは Direct-Customer-Alerts アラームです。 | | Amazon EC2 インスタンス - Windows | 最大 LogicalDisk % 空き容量 <= 5%、5 分間、6 回連続。 | \$1\$1EC2::InstanceId\$1: ディスク使用率が高すぎる - \$1\$1EC2::Disk::UUID\$1 CloudWatch アラーム。Amazon EC2 Windows インスタンス内の論理ディスク (ファイルシステムパーティション) の空き領域の割合が、事前定義されたしきい値を超えていることを示します。ディスク容量が不足すると、ディスク容量が不足する可能性があります。 これらは Direct-Customer-Alerts アラームです。 | | Amazon EFS | AMSEFSBurstCreditBalanceExhausted。 BurstCreditBalance が 15 分間 1000 未満。 | \$1\$1EFS::FileSystemId\$1: EFS: バーストクレジット残高 Amazon EFS ファイルシステムの BurstCreditBalance の CloudWatch アラーム。 | | Amazon EFS | AMSEFSClientConnectionsLimit。 ClientConnections > 24,000 を 15 分間。 | \$1\$1EFS::FileSystemId\$1: EFS: クライアント接続の制限 Amazon EFS ファイルシステムの ClientConnections の CloudWatch アラーム。 | | Amazon EFS | AMSEFSThroughputUtilizationLimit。 EFS スループット使用率 > 80% を 1 時間。 | \$1\$1EFS::FileSystemId\$1: EFS: スループット使用率の制限 Amazon EFS ファイルシステムのスループット使用率に関する CloudWatch アラーム。 | | Amazon EFS | AMSEFSPercentIOLimit。 PercentIOLimit > 95 を 75 分間。 | \$1\$1EFS::FileSystemId\$1: EFS: PercentIOLimit Amazon EFS ファイルシステムの PercentIOLimit の CloudWatch アラーム。 | | Amazon EKS | 「Amazon EKS」を参照してください[AMS Accelerate での Amazon EKS のモニタリングとインシデント管理のベースラインアラート](acc-baseline-eks-alerts.md)。 | | | Elastic Load Balancing インスタンス | SpilloverCountBackendConnectionErrors > 1 を 1 分間、15 回連続。 | Classic LoadBalancer のスピルオーバーカウントアラーム サージキューがいっぱいであるために拒否されたリクエストの数が過剰である場合、CloudWatch アラームが発生します。 | | Elastic Load Balancing インスタンス | HTTPCode\$1ELB\$15XX\$1Count 合計 > 0 を 5 分間、連続 3 回。 | ロードバランサーから送信される HTTP 5XX レスポンスコードの過剰数に関する CloudWatch アラーム。 | | Elastic Load Balancing インスタンス | SurgeQueueLength > 100 を 1 分間、15 回連続。 | Classic LoadBalancer サージキューの長さアラーム。 過剰な数のリクエストがルーティングを保留している場合、CloudWatch アラームが発生します。 | | FSx for ONTAP | AMSFSXONTAPIOPSUtilization。 FSX:ONTAP IOPS 使用率 > 80% を 2 時間。 | \$1\$1FSx::FileSystemId\$1: FSX:ONTAP IOPS 使用率 FSx for ONTAP インスタンスの IOPS 使用率制限に関する CloudWatch アラーム。 | | FSx for ONTAP | AMSFSXONTAPThroughputUtilization。 FSX:ONTAP スループット使用率 > 80% を 2 時間。 | \$1\$1FSx::FileSystemId\$1: FSX:ONTAP スループット使用率 FSx for ONTAP ボリュームのスループット制限に関する CloudWatch アラーム。 | | FSx for ONTAP | AMSFSXONTAPVolumeInodeUtilization。 FSX:ONTAP Inode 使用率 > 80% を 2 時間。 | \$1\$1FSx::FileSystemId\$1:\$1\$1FSx::ONTAP::VolumeId\$1 FSX:ONTAP Inode 使用率 FSx for ONTAP ボリュームのファイル容量使用率制限に関する CloudWatch アラーム。 | | FSx for ONTAP | AMSFSXONTAPVolumeCapacityUtilization。 FSX:ONTAP ボリューム容量使用率 > 80% を 2 時間。 | \$1\$1FSx::FileSystemId\$1:\$1\$1FSx::ONTAP::VolumeId\$1 FSx for ONTAP ボリュームのボリューム容量使用率制限に関する CloudWatch アラーム。 | | FSx for Windows File Server | AMSFSXWindowsThroughputUtilization。 FSX:Windows スループット使用率 > 80% を 2 時間。 | \$1\$1FSx::FileSystemId\$1: FSX:Windows スループット使用率 FSx for Windows File Server インスタンスのスループット制限に関する CloudWatch アラーム。 | | FSx for Windows File Server | AMSFSXWindowsIOPSUtilization。 FSX:Windows IOPS 使用率 > 80% を 2 時間。 | \$1\$1FSx::FileSystemId\$1: FSX:Windows IOPS 使用率 FSx for Windows File Server インスタンスの IOPS 使用率制限に関する CloudWatch アラーム。 | | GuardDuty サービス | 該当なし。すべての検出結果 (脅威の目的) がモニタリングされます。各検出結果はアラートに対応します。 GuardDuty の検出結果の変更。このような変更には新しく生成された結果や、既存の結果の後続のすべての発生を含みます。 | サポートされている GuardDuty 検出結果タイプのリストについては、[GuardDuty Active Finding Types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html)」を参照してください。 | | ヘルス | AWS Health Dashboard | AMS によってモニタリングされるサービスに関連して AWS Health Dashboard （AWS Health) イベントのステータスが変更されると、通知が送信されます。詳細については、[「サポートされているサービス](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-sd.html#acc-supported-services)」を参照してください。 | | IAM | Amazon EC2 IAM インスタンスプロファイルが存在しません。 IAM インスタンスプロファイルがありません。 | Amazon EC2 IAM インスタンスプロファイルを置き換える手順については、「IAM [ロールを置き換える」の「IAM ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#replace-iam-role)ドキュメント」を参照してください。 | | IAM | Amazon EC2 IAM インスタンスプロファイルのポリシーが多すぎます。 IAM インスタンスプロファイルには 10 個のポリシーがあり、追加のポリシーを追加することはできません。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/accelerate-guide/monitoring-default-metrics.html) AMS に必要なポリシーについては、*「AMS Accelerate ユーザーガイド*: 」を参照してください[IAM アクセス許可の変更の詳細](inst-auto-config-details-iam.md)。 | | Macie | 新しく生成されたアラートと既存のアラートの更新。 Macie は検出結果の変更を検出します。このような変更には新しく生成された結果や、既存の結果の後続のすべての発生を含みます。 | Amazon Macie アラート。サポートされている Amazon Macie アラートタイプのリストについては、[Amazon Macie の検出結果の分析](https://docs.aws.amazon.com/macie/latest/user/findings.html)」を参照してください。Macie はすべてのアカウントで有効になっていないことに注意してください。 | | NATGateways | PacketsDropCount : packetsdropcount が 15 分間で > 0 の場合に警告 | NatGateway PacketsDropCount 値が 0 より大きい場合は、NAT ゲートウェイで進行中の一時的な問題を示している可能性があります。 | | NATGateways | ErrorPortAllocation : NAT ゲートウェイが 15 分間の評価期間にわたってポートを割り当てられなかった場合のアラーム | NatGateway ErrorPortAllocation NAT ゲートウェイが送信元ポートを割り当てられなかった回数。0 より大きい値は、開いている同時接続が多すぎることを示します。 | | OpenSearch クラスター | ClusterStatus 赤の最大値は >= 1 で 1 分間、連続 1 回です。 | ClusterStatus Red CloudWatch アラーム。ドメイン内の保管中のデータの暗号化に使用される AWS KMS 暗号化キーは無効になっています。通常のオペレーションを復元するために、再度有効にしてください。詳細については、[「Red Cluster Status](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-red-cluster-status)」を参照してください。 | | OpenSearch ドメイン | KMSKeyError >= 1 を 1 分間、連続 1 回。 | KMS キーエラー CloudWatch アラーム。少なくとも 1 つのプライマリシャードとそのレプリカがノードに割り当てられていません。詳細については、[「Amazon OpenSearch Service の保管中のデータの暗号化](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html)」を参照してください。 | | OpenSearch ドメイン | KMSKeyInaccessible >= 1 を 1 分間、連続 1 回。 | KMS キーにアクセスできないエラー CloudWatch アラーム。少なくとも 1 つのプライマリシャードとそのレプリカがノードに割り当てられていません。詳細については、[「Amazon OpenSearch Service の保管中のデータの暗号化](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/encryption-at-rest.html)」を参照してください。 | | OpenSearch ドメイン | ClusterStatus 黄色の最大値は >= 1 で 1 分間、連続 1 回です。 | ClusterStatus 黄 少なくとも 1 つのレプリカシャードがノードに割り当てられていません。詳細については、[「黄色のクラスターステータス](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-yellow-cluster-status)」を参照してください。 | | OpenSearch ドメイン | FreeStorageSpace 最小は <= 20480 で 1 分間、連続して 1 回です。 | 空きストレージ容量が少ない クラスターのノードの空きストレージ容量が 20 GiB に下がっています。詳細については、[「使用可能なストレージ容量がない](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-watermark)」を参照してください。 | | OpenSearch ドメイン | ClusterIndexWritesBlocked >= 1 を 5 分間、1 回連続。 | クラスターインデックスの書き込みがブロックされました クラスターは書き込みリクエストをブロックしています。詳細については、「[ClusterBlockException](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#troubleshooting-cluster-block)」を参照してください。 | | OpenSearch ドメイン | ノード 最小 < x 1 日、連続 1 回。 | ノードダウン x はクラスター内のノード数です。このアラームは、クラスター内の少なくとも 1 つのノードが 1 日間にわたってアクセスできない状態を意味します。詳細については、[「失敗したクラスターノード](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-failed-cluster-nodes)」を参照してください。 | | OpenSearch ドメイン | CPUUtilization 平均 >= 15 分間 80%、連続 3 回。 | データノードの CPU 使用率が高い 100% の CPU 使用率は珍しくありませんが、高い平均値が持続する場合は問題があります。既存のインスタンスタイプの適切なサイズ設定やインスタンスの追加を検討してください。 | | OpenSearch ドメイン | JVMMemoryPressure 最大 >= 5 分間 80%、連続 3 回。 | データノードのメモリ使用率が高い 使用量が増加した場合にクラスターでメモリ不足エラーが発生する可能性があります。垂直スケーリングを検討してください。OpenSearch は、Java ヒープにインスタンスの RAM の半分を使用し、ヒープサイズは 32 GiB までです。インスタンスは最大 64 GiB の RAM まで垂直スケーリングでき、それ以上はインスタンスを追加することで水平方向にスケーリングできます。 | | OpenSearch ドメイン | MasterCPUUtilization 平均 >= 15 分間 50%、連続 3 回。 | マスターノード CPU 使用率が高い [ 専用マスターノード](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-managedomains-dedicatedmasternodes.html)には、より大きなインスタンスタイプを使用することを検討してください。クラスターの安定性と [Blue/Green デプロイ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-managedomains-configuration-changes)に関わるため、専用マスターノードの CPU の平均使用率はデータノードよりも低くする必要があります。 | | OpenSearch ドメイン | MasterJVMMemoryPressure 最大 >= 15 分間 80%、連続 1 回。 | マスターノードの JVM メモリプレッシャーが高い [ 専用マスターノード](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-managedomains-dedicatedmasternodes.html)には、より大きなインスタンスタイプを使用することを検討してください。クラスターの安定性と [Blue/Green デプロイ](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-managedomains-configuration-changes)に関わるため、専用マスターノードの CPU の平均使用率はデータノードよりも低くする必要があります。 | | OpenSearch インスタンス | AutomatedSnapshotFailure maximum は >= 1 で 1 分間、連続 1 回です。 | 自動スナップショットの失敗 CloudWatch アラーム。自動スナップショットが失敗しました。多くの場合、この失敗によってクラスター状態が赤になります。詳細については、[「Red Cluster Status](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/aes-handling-errors.html#aes-handling-errors-red-cluster-status)」を参照してください。 | | Amazon RDS | 平均 CPU 使用率 > 15 分間 90%、2 回連続。 | \$1\$1RDS::DBInstanceIdentifier\$1: CPUUtilization CloudWatch アラーム。 | | Amazon RDS | DiskQueueDepth の合計 > 1 分間 75%、連続 15 回。 | \$1\$1RDS::DBInstanceIdentifier\$1: DiskQueue CloudWatch アラーム。 | | Amazon RDS | 平均 FreeStorageSpace < 1,073,741,824 バイト、5 分間、2 回連続。 | \$1\$1RDS::DBInstanceIdentifier\$1: FreeStorageSpace CloudWatch アラーム。 | | Amazon RDS | 低ストレージアラート DB インスタンスに割り当てられたストレージが使い果たされるとトリガーされます。 | RDS-EVENT-0007 の詳細については、[「Amazon RDS イベント通知の使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html)」を参照してください。 | | Amazon RDS | DB インスタンスが失敗する DB インスタンスは、互換性のない設定または基本的なストレージの問題により失敗しました。DB インスタンスのポイントインタイムの復元をスタートします。 | RDS-EVENT-0031 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | RDS -0034 フェイルオーバーは試行されません。 Amazon RDS はリクエストされたフェイルオーバーを実行できません。これは、DB インスタンスでフェイルオーバーが最近発生したためです。 | RDS-EVENT-0034 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | RDS - 0035 DB インスタンスの無効なパラメータ たとえば、このインスタンスクラスに対してメモリ関連のパラメータが高すぎるため、MySQL を起動できなかったため、アクションはメモリパラメータを変更して DB インスタンスを再起動することです。 | RDS-EVENT-0035 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | 無効なサブネット IDsインスタンス DB インスタンスが互換性のないネットワーク上にあります。指定したサブネット ID の一部は無効であるか、存在しません。 | サービスイベント。RDS-EVENT-0036 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | RDS-0045 DB インスタンスのリードレプリカエラー リードレプリケーションプロセスでエラーが発生しました。詳細については、イベントメッセージを参照してください。リードレプリカエラーのトラブルシューティングについては、[MySQL リードレプリカの問題のトラブルシューティング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_MySQL.Replication.ReadReplicas.html#USER_ReadRepl.Troubleshooting)」を参照してください。 | RDS-EVENT-0045 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | RDS-0057 statspack ユーザーアカウントの作成中にエラーが発生しました リードレプリカのレプリケーションが終了しました。 | サービスイベント。RDS-EVENT-0057 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | RDS-0058 DB インスタンスの読み取りレプリケーションが終了しました Statspack ユーザーアカウント PERFSTAT の作成中にエラーが発生しました。Statspack オプションを追加する前に、アカウントを削除します。 | サービスイベント。RDS-EVENT-0058 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | DB インスタンス復旧の開始 SQL Server DB インスタンスは、ミラーを再構築しています。ミラーが再構築されるまで、パフォーマンスが低下します。FULL ではない復旧モデルのデータベースが見つかりました。復旧モデルが FULL に戻され、ミラーリング復旧が開始されました (: [,...])。 | サービスイベント。RDS-EVENT-0066 の詳細については[、Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)を参照してください。 | | Amazon RDS | DB クラスターのフェイルオーバーが失敗しました。 | RDS-EVENT-0069 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | 無効なアクセス許可復旧 S3 バケット Amazon S3 バケットにアクセスして SQL Server のネイティブバックアップと復元を行うための IAM ロールが正しく設定されていません。詳細については、[「ネイティブバックアップと復元のセットアップ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html#SQLServer.Procedural.Importing.Native.Enabling)」を参照してください。 | サービスイベント。RDS-EVENT-0081 の詳細については[、Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)を参照してください。 | | Amazon RDS | Aurora は、Amazon S3 バケットからバックアップデータをコピーできませんでした。 | RDS-EVENT-0082 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | DB インスタンスが割り当てられたストレージの 90% 以上を消費した場合の低ストレージアラート。 | サービスイベント。RDS-EVENT-0089 の詳細については、[Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)を参照してください。 | | Amazon RDS | Aurora Serverless DB クラスターのスケーリングが失敗したときの通知サービス。 | サービスイベント。RDS-EVENT-0143 は、[Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)で詳細を表示します。 | | Amazon RDS | DB インスタンスは無効な状態です。操作は必要ありません。オートスケーリングは後で再試行されます。 | RDS-EVENT-0219 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | DB インスタンスがストレージフルのしきい値に達し、データベースがシャットダウンされました。 | RDS-EVENT-0221 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | このイベントは、Amazon RDS インスタンスストレージの自動スケーリングがスケーリングできないことを示します。自動スケーリングが失敗した理由は複数ある可能性があります。 | RDS-EVENT-0223 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | ストレージのオートスケーリングにより、保留中のスケールストレージタスクの最大ストレージしきい値到達がトリガーされました。 | RDS-EVENT-0224 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | DB インスタンスのストレージタイプが、アベイラビリティーゾーンで現在使用できないタイプです。オートスケーリングは後で再試行されます。 | RDS-EVENT-0237 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | サブネットに十分な IP アドレスがないため、Amazon RDS はプロキシの容量をプロビジョニングできませんでした。 | RDS-EVENT-0243 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon RDS | のストレージ AWS アカウント が、許可されたストレージクォータを超えています。 | RDS-EVENT-0254 の詳細については、[「Amazon RDS イベントカテゴリとイベントメッセージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html#USER_Events.Messages)」を参照してください。 | | Amazon Redshift クラスター | メンテナンスモードでない場合のクラスターの状態 < 1 で 5 分間 | RedshiftClusterHealthStatus 詳細については、[CloudWatch メトリクスを使用した Amazon Redshift のモニタリング](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics-listing.html)」を参照してください。 | | Site-to-Site VPN | VPNTunnelDownTunnelState <= 1 分間 0、連続 20 回。 | \$1\$1AWS::EC2::VpnConnectionId\$1 - VPNTunnelDown TunnelState は、両方のトンネルがダウンしている場合は 0、1 つのトンネルがアップしている場合は .5、両方のトンネルがアップしている場合は 1.0 です。 | | Systems Manager エージェント | Systems Manager によって管理されていない EC2 インスタンス SSM エージェントがインストールされていません。SSM エージェントはインスタンスにインストールされていますが、エージェントサービスは実行されていません。SSM エージェントには、 AWS Systems Manager サービスへのネットワークルートがありません。 | Systems Manager エージェントを中断させる追加の条件があります。詳細については、[「マネージドノードの可用性のトラブルシューティング](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-managed-instances.html)」を参照してください。 | 修復作業の詳細については、「」を参照してください[アラートの AMS 自動修復](auto-remediation.md)。 [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/e9hbG-FAeFM/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/e9hbG-FAeFM) # AMS でのアプリケーション対応インシデント通知 アプリケーション対応の自動インシデント通知を使用して、AMS がユーザーに代わって作成するサポートケースの通信エクスペリエンスをカスタマイズします。この機能を使用すると、AMS は [AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html) からカスタムワークロード設定を取得し、アプリケーションに関するメタデータを使用して AMS インシデント通信を強化し、ユーザーに代わって AMS によって作成されたサポートケースの重要度をカスタマイズします。この機能を使用するには、まず AWS Service Catalog AppRegistry にオンボードする必要があります。 AMS Accelerate のモニタリングのデフォルトの詳細については、「」を参照してください[AMS Accelerate でのモニタリングとイベント管理](acc-mon-event-mgmt.md)。 ## AppRegistry にオンボードしてアプリケーションを作成する AppRegistry にオンボードするには、[AppRegistry 管理者ガイドの「AppRegistry の開始方法](https://docs.aws.amazon.com/servicecatalog/latest/arguide/getting-started-ar.html)」を参照してください。 *AWS Service Catalog AppRegistry * オンボーディング後、次のいずれかの方法を使用してアプリケーションを作成します。 1. **AWS コンソール：** AWS コンソールを使用して AppRegistry でアプリケーションを作成する方法の詳細については、*AWS Service Catalog AppRegistry 管理者ガイド*の[「アプリケーションの作成](https://docs.aws.amazon.com/servicecatalog/latest/arguide/create-apps.html)」を参照してください。 1. **CloudFormation:** AppRegistry アプリケーションは、他のリソースを定義するのと同じように定義できます。詳細については、「 *CloudFormation ユーザーガイド*」の[AWS Service Catalog AppRegistry リソースタイプのリファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_ServiceCatalogAppRegistry.html)」を参照してください。 1. **AMS オートメーション：** アプリケーション登録プロセスを簡素化するために、AMS は SSM オートメーションドキュメント を提供します`AWSManagedServices-CreateAppRegistryApplication`。この方法を使用するには、[https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/) の AWS Systems Manager コンソールから、または次の例で説明 AWS CLI されているように を使用して、 ドキュメントを呼び出します。 ``` # The following registers a new application with customized severity aws ssm start-automation-execution \ --document-name "AWSManagedServices-CreateAppRegistryApplication" \ --parameters '{"ResourceAssociationType":["TAGS"],"AppTagValue":["MyApp"],"CFNStackNames":[],"ApplicationName":["BananaStand"],"ApplicationDescription":["This is my banana stand application"],"AppCriticality":["normal"],"AutomationAssumeRole":["arn:aws:iam::123456789012:role/SSMAdminRole"]}' \ --region us-east-1 # The following registers a new application with no customizations aws ssm start-automation-execution \ --document-name "AWSManagedServices-CreateAppRegistryApplication" \ --parameters '{"ResourceAssociationType":["TAGS"],"AppTagValue":["MyApp"],"CFNStackNames":[],"ApplicationName":["BananaStand"],"ApplicationDescription":["This is my banana stand application"],"AppCriticality":["unset"],"AutomationAssumeRole":["arn:aws:iam::123456789012:role/SSMAdminRole"]}' \ --region us-east-1 # You can also register applications using CloudFormation stacks aws ssm start-automation-execution \ --document-name "AWSManagedServices-CreateAppRegistryApplication" \ --parameters '{"ResourceAssociationType":["STACKS"],"AppTagValue":[""],"CFNStackNames":["arn:aws:cloudformation:us-east-1:123456789012:stack/stack-2343eddq/1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p"],"ApplicationName":["BananaStand"],"ApplicationDescription":["This is my banana stand application"],"AppCriticality":["unset"],"AutomationAssumeRole":["arn:aws:iam::123456789012:role/SSMAdminRole"]}' \ --region us-east-1 ``` ## タグを作成してケースエンリッチメントを有効にする AMS がアプリケーションメタデータにアクセスする前に、アプリケーションにタグを付ける必要があります。次の表に、必要なタグを示します。 プレフィックスが付いたタグ`ams:rt:`は、[Resource Tagger](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-resource-tagger.html) を通じて適用されます。 | タグキー | タグ値 | | --- | --- | | ams マネージド | true | | ams:rt:ams-managed | true | ## アプリケーションの AMS サポートケースの重要度をカスタマイズする アプリケーションが組織にとってどの程度重要であるかを指定することで、AMS が作成したサポートケースの重要度をカスタマイズできます。この設定は、AppRegistry のアプリケーションに関連付けられた属性グループによって制御されます。属性グループ名の名前は、次のパターンと一致する必要があります。 ``` AMS..CommunicationOptions ``` 前述のパターンでは、 はアプリケーションの作成時に AppRegistry で使用される名前と一致する`ApplicationName`必要があります。 コンテンツの例： ``` { "SchemaVersion": "1.0", "Criticality": "low" } ``` **SchemaVersion** これにより、使用しているスキーマバージョンと使用可能な機能のサブセットが決まります。 | スキーマバージョニング | 機能 | | --- | --- | | 1.0 | 重要度値に基づいてカスタマイズされたサポートケースの重要度 | **重要度** このアプリケーションの重要度によって、AMS 自動システムによって作成されたサポートケースの重要度が決まります。 有効な値: ``` low|normal|high|urgent|critical ``` 重要度レベルの詳細については、 *AWS サポート API リファレンス*の[SeverityLevel](https://docs.aws.amazon.com/awssupport/latest/APIReference/API_SeverityLevel.html)」を参照してください。 必須: はい ## 必要なアクセス許可を確認する この機能を使用するには、AMS は次のアクセス AWS Identity and Access Management 許可にアクセスする必要があります。 + iam:ListRoleTags + iam:ListUserTags + resourcegroupstaggingapi:GetResources + servicecatalog-appregistry:GetApplication + servicecatalog-appregistry:ListAssociatedAttributeGroups + servicecatalog-appregistry:GetAttributeGroup **重要** 上記のアクションを拒否する IAM ポリシーまたはサービスコントロールポリシー (SCP) がないことを確認します。 API コールは `ams-access-admin`ロールによって行われます。以下は、表示される可能性のある内容の例です。 ``` arn:aws:sts::111122223333:assumed-role/ams-access-admin/AMS-AMSAppMetadataLookup-* ``` # アラームマネージャーの高速化 AMS Accelerate は、タグベースのアラームマネージャーを使用して AWS リソースにアラームを適用し、ベースラインモニタリング戦略を実装し、すべての AWS リソースがモニタリングおよび保護されるようにします。タグベースの Alarm Manager と統合することで、リソースのタイプ、プラットフォーム、その他のタグに基づいてリソースの設定 AWS をカスタマイズして、リソースがモニタリングされるようにできます。Alarm Manager は、オンボーディング中に Accelerate アカウントにデプロイされます。 ## Alarm Manager の仕組み アカウントが AMS Accelerate にオンボーディングされると、設定プロファイルと呼ばれる 2 つの JSON ドキュメントが [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) のアカウントにデプロイされます。どちらのプロファイルドキュメントも、Alarm Manager アプリケーションと AMS Accelerate インフラストラクチャ環境にあります。 2 つの設定プロファイルには、**AMSManagedAlarms** (デフォルトの設定プロファイル) と**CustomerManagedAlarms** (カスタマイズ設定プロファイル) という名前が付けられています。 + デフォルトの設定プロファイル： + このプロファイルにある設定には、AMS Accelerate がすべてのカスタマーアカウントにデプロイするデフォルト設定が含まれています。この設定にはデフォルトの AMS Accelerate モニタリングポリシーが含まれています。AMS Accelerate はいつでもこのプロファイルを更新し、変更を消去できるため、変更しないでください。 + これらの定義のいずれかを変更または無効にする場合は、[Accelerate アラームのデフォルト設定の変更](acc-mem-modify-default.md)「」および「」を参照してください[デフォルトの Accelerate アラーム設定を無効にする](acc-mem-disable-default-config.md)。 + カスタマイズ設定プロファイル： + このプロファイルの設定はすべてお客様によって完全に管理されます。明示的にリクエストしない限り、AMS Accelerate はこのプロファイルを上書きしません。 + このプロファイルで任意のカスタムアラーム定義を指定でき、AMS Accelerate が管理するデフォルト設定への変更を指定することもできます。詳細については、「[Accelerate アラームのデフォルト設定の変更](acc-mem-modify-default.md)」および「[デフォルトの Accelerate アラーム設定を無効にする](acc-mem-disable-default-config.md)」を参照してください。 + このプロファイルを更新すると、Alarm Manager は AWS アカウント内のすべての関連リソースで変更を自動的に適用します。変更は自動的に有効になりますが、有効になるまでに最大 60 分かかる場合があります。 + このプロファイルは、 AWS マネジメントコンソール または AWS CLI/SDK ツールを使用して更新できます。設定の更新手順については、[AWS AppConfig ユーザーガイド](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)を参照してください。 + カスタマイズプロファイルは最初は空ですが、デフォルト設定に加えて、プロファイルドキュメントに配置されたアラーム定義が適用されます。 Alarm Manager によって作成されたすべての CloudWatch アラームには、タグキー **ams:alarm-manager:managed** とタグ値 **true** が含まれています。これは、Alarm Manager が作成したアラームのみを管理し、独自のアラームに干渉しないようにするためです。これらのタグは、Amazon CloudWatch [ListTagsForResource](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_ListTagsForResource.html) API を使用して確認できます。 **重要** カスタムアラーム定義とデフォルトのアラーム定義が同じ ConfigurationID で指定されている場合 (「」を参照[高速設定プロファイル: モニタリング](acc-mem-config-doc-format.md)）、カスタム定義はデフォルトのルールよりも優先されます。 # Accelerate Alarm Manager の開始方法 デフォルトでは、AMS Accelerate を使用してオンボードすると、設定が にデプロイされ AWS AppConfig、リソースのアラームベースラインが定義されます。アラーム定義は、**ams:rt:\$1** タグを持つリソースにのみ適用されます。これらのタグは、 を使用して適用することをお勧めします[リソースタガーの高速化](acc-resource-tagger.md)。AMS Accelerate に管理するリソースを知らせるために、基本的な Resource Tagger 設定をセットアップします。 Resource Tagger を使用して、タグキー **ams:rt:ams-managed**with tag value **true** を AMS Accelerate でモニタリングするすべてのリソースに適用します。 以下は、すべての Amazon EC2 インスタンスのモニタリングをオプトインするために使用できる Resource Tagger カスタマイズプロファイルの例です。一般情報については、「[リソースタガーの高速化](acc-resource-tagger.md)」を参照してください。 ``` { "AWS::EC2::Instance": { "AMSManageAllEC2Instances": { "Enabled": true, "Filter": { "InstanceId": "*" }, "Tags": [ { "Key": "ams:rt:ams-managed", "Value": "true" } ] } } } ``` この Resource Tagger 設定を適用する方法については、「」を参照してください[Resource Tagger 設定の表示または変更](acc-rt-using.md#acc-rt-make-changes)。 # アラームマネージャータグの高速化 デフォルトでは、AMS Accelerate を使用してオンボードすると、設定が にデプロイされ AWS AppConfig、リソースのアラームベースラインが定義されます。アラーム定義は、**ams:rt:\$1** タグを持つリソースにのみ適用されます。これらのタグは、 を使用して適用することをお勧めします[リソースタガーの高速化](acc-resource-tagger.md)。AMS Accelerate に管理するリソースを知らせるために、基本的な Resource Tagger 設定をセットアップします。 Resource Tagger を使用して、タグキー **ams:rt:ams-managed**with tag value **true** を AMS Accelerate でモニタリングするすべてのリソースに適用します。 **Topics** + [Resource Tagger を使用してタグを高速化する](acc-mem-tag-alarms-use-rt.md) + [Resource Tagger を使用せずにタグを高速化する](acc-mem-tags-no-rt.md) + [を使用してタグを高速化する CloudFormation](acc-mem-tags-cfn.md) + [Terraform を使用してタグを高速化する](acc-mem-tags-terraform.md) # Resource Tagger を使用してタグを高速化する タグベースのアラームマネージャーは、リソースごとの CloudWatch アラームのライフサイクルを管理しますが、マネージドリソースには AMS Accelerate で定義された特定のタグが必要です。Resource Tagger を使用して AMS マネージドアラームのデフォルトセットを Linux および Windows ベースのインスタンスの両方に適用するには、次の手順に従います。 1. アカウント内の [AppConfig](https://console.aws.amazon.com/systems-manager/appconfig/) コンソールを参照します。 1. ResourceTagger アプリケーションを選択します。 1. **設定プロファイル**タブを選択し、**CustomerManagedTags** を選択します。 1. **Create** をクリックして、新しいプロファイルを作成します。 1. **JSON** を選択し、設定を定義します。フィルターとプラットフォームの定義のその他の例については、「」を参照してください[リソースタガーの高速化](acc-resource-tagger.md)。 ``` { "AWS::EC2::Instance": { "MonitorAllInstances": { "Enabled": true, "Filter": { "Platform": "*" }, "Tags": [ { "Key": "ams:rt:ams-managed", "Value": "true" } ] } } } ``` 1. **ホストされた設定バージョンの作成** をクリックします。 1. **デプロイの開始** をクリックします。 1. 次のデプロイの詳細を定義します。 ``` Environment: AMSInfrastructure Hosted configuration version: