AWS監視のベストプラクティスな考え方とは？CloudWatchの推奨設定を解説

AWS監視のベストプラクティスとは

AWS監視のベストプラクティスとは、AWS環境の各リソースの状態を継続的に把握し、問題発生時に迅速に対応するための手法や考え方のことを指します。

CloudWatchを活用し、CPU使用率、ディスクI/O、ネットワークなどの重要なメトリクスを監視することで、システムの異常を早期に検知できます。

さらに、アラートを設定し、異常発生時に自動で通知を受け取れるようにすることで、人的ミスを減らし、迅速な対応を可能にします。

監視すべきことを「AWS Well-Architected Framework」から確認

AWS Well-Architected Framework は、AWS上で安全で効率的なクラウド環境を構築するための設計原則とベストプラクティスをまとめたフレームワークです。

このフレームワークは、クラウド設計の際に考慮すべき重要な要素を以下の6つの柱に分類し、各柱においてベストプラクティスを提示しています。

運用上の優秀性
セキュリティ
信頼性
パフォーマンス効率
コスト最適化
サスティナビリティ

6つの柱の中で、監視に関する3つの項目が記載されています。その3つの項目について詳しく解説します。

ワークロードの状態を把握する

1つ目の柱である運用上の優秀性の項目に、ワークロード（企業のアプリケーションやシステム）の状態を把握することと記載されています。ワークロードを設計する際には、以下の項目をチェックできるような設計を心がけましょう。

AWSリソースの状態の変化
ユーザーのアクティビティ
アクセス権限
各リソースの使用量

また、アプリ開発段階では、規制やコンプライアンスに抵触していないか、本番稼働中には、パフォーマンスやコストが最適化されているかを、常に状態を把握することが重要と記されています。

インシデント対応

セキュリティの柱の中に、インシデント対応の項目があり、その項目の中にも監視の重要性が書かれています。優れたセキュリティ対策を行っていても、障害やインシデントが発生します。そこで、インシデント発生時、問題の早期発見のために監視が欠かせません。

常時システムの監視を行うことで、障害への迅速な対応や復旧が可能になります。また、不正アクセス等が発生した場合にも自動でアクセス権をつけて、システムを隔離させることで、ビジネスへの被害も最小限に抑えられます。

イベントの自動化

信頼性の柱の中に、変更管理の項目があります。変更管理の自動化を行う上でも監視が重要視されています。

一定期間利用していないリソースを自動で停止・削除
サーバーなどのリソースの自動スケール
災害からの自動復旧

上記の自動化を行うためには、リソースを監視し、ログを分析する必要があります。例えば、Webサーバーを自動スケールする場合は、アクセス数やEC2の使用率を常に監視して、アクセスが急増した場合は、サーバーを自動で増やすなどの対応が可能です。

AWS監視を行うための6つのベストプラクティス

AWS環境の監視は、システムの安定性、セキュリティ、コスト最適化にとって非常に重要です。適切な監視体制を構築することで、問題の早期発見、迅速な対応、そしてシステム全体の効率化を図ることができます。
ここでは、AWS監視を行う上での6つのベストプラクティスを解説します。

監視の目的を定義する

AWS環境の監視を始める前に、監視の目的を明確に定義することが重要です。

上記項目に対して、具体的な数値目標を立てることで、監視の効果を最大限に引き出すことができます。目的が明確であれば、適切なKPIを設定し、効果的なモニタリングが可能になります。

AWSリソースの監視計画を立てる

監視を効果的に行うためには、まず監視計画を立てることが必要です。計画フェーズで以下を定義しましょう。

監視対象のリソース
監視する項目
使用する監視ツール・サービス
ログを取得する頻度
監視データの収集方法・解析方法
レポート作成の手順

この計画がしっかりしていると、AWSリソースの運用状況を継続的に把握でき、異常が発生した際に迅速かつ的確な対応が可能になります。計画は定期的に見直し、運用環境の変化に対応させることも重要です。

モニタリングの優先事項を決定する

全てのリソースを同じ優先度で監視することは現実的ではなく、AWSのベストプラクティスではありません。監視業務の優先事項を決定し、重要度に応じてリソースを分類することが重要です。

例えば、ビジネスに直結する重要なシステムやデータは最優先で監視し、それ以外のリソースは必要最低限の項目のみ監視を行います。これにより、リソースが限られている場合でも、最も重要なリソースに監視リソースを集中させることができます。

監視する頻度・ログの保管期間をリソースごとに決める

AWS環境では、様々なリソース（EC2インスタンス、RDSデータベース、S3バケットなど）が利用されます。各リソースの特性や重要度に応じて、適切な監視頻度とログの保管期間を設定することが重要です。

頻繁な状態変化が想定されるリソースは、1分単位や数秒単位での高頻度監視が有効です。
状態変化が比較的少ないリソースは、数時間単位や1日単位の低頻度監視で十分なケースが多いです。

監査目的やトラブルシューティングに必要なセキュリティログは、長期間保存しておく必要がありますが、その他のデータは削除することで、コストを抑えられます。

最適な監視ツールを選ぶ

AWS環境を監視するためには、適切な監視ツールの選定が必要です。CloudWatchやAWS X-Ray、サードパーティー製の監視ツールなど、下記項目を考慮した上で、ニーズに合ったツールを選びましょう。

監視の目的
リソースの特性
組織の規模
予算

複数のツールを併用する場合は、各ツールの機能やデータ連携のしやすさも確認し、最適な組み合わせを構築することが重要です。

監視アラート発生時の対応フローを作成

監視をするだけでは、障害やエラーの対策は不十分です。監視アラートが発生した際の対応フローを事前に作成しておくことで、問題が発生した際に迅速かつ適切に対応できます。

アラートの重要度に応じた対応手順
担当者の割り当て
エスカレーション方法

などを、あらかじめ決定し、担当者に周知しておきましょう。これにより、アラート発生時に混乱を防ぎ、組織全体が迅速に行動できる体制を整えられます。

ベストプラクティスなAWS監視の具体例

ここからは、AWSの監視における具体的なベストプラクティスを実例を交えて紹介します。これらの例を参考にすることで、効率的かつ効果的なAWS監視体制の構築が可能です。

CloudWatchを活用

マルチクラウドの監視や特別な事情がなければ、AWS環境の監視は、Amazon CloudWatchを使用することがベストプラクティスです。

Amazon CloudWatchを利用することで、リソースの監視やログの収集、メトリクスの可視化が可能です。これらをリアルタイムで監視し、異常が発生した場合にはアラートを発信でき、問題の早期発見と解決に貢献します。

CloudTrailで証跡確認

証跡確認のために、CloudTrailを使用することもベストプラクティスの一つです。

AWS CloudTrailは、AWSアカウント内で発生する全てのアクティビティ（誰が・いつ・何を行ったか）を記録し、セキュリティとコンプライアンスの管理が可能なサービスです。監査やセキュリティインシデントの調査時に役立てることもできます。

例えば、予期しないリソースの変更が発生した場合、その操作を行ったユーザーや発生時刻をすぐに確認し、不正アクセスや不適切な操作の迅速な対処が可能になります。

AWS Budgetsで課金アラートの設定

AWS Budgetsは、コスト管理のためのツールです。AWS Budgetsを使用することで、月次予算を設定し、実際のコストが設定した予算に近づいた際に、メールやSNSなどでアラートを受け取ることができます。

また、特定のサービスやプロジェクトごとに予算を設定することで、詳細なコスト管理を行い、リソースの無駄遣いを防ぐことができます。

監視作業を自動化する

AWSの監視作業の自動化もベストプラクティスの一つです。自動化することで、人的ミスを減らし、運用効率を大幅に向上させることができます。

たとえば、Amazon EventBridgeやAWS Lambdaを活用して、特定のイベントが発生した際に自動的にスクリプトを実行したり、システムの修復プロセスを開始することが可能です。また、インフラの変更管理を自動化することで、リソースのプロビジョニングやスケーリングも効率化され、運用コストの削減につながります。

Amazon CloudWatchのサービス別推奨設定

AWSリソースの監視は、基本的にAmazon CloudWatchを利用することを推奨しています。ここからは、具体的にAmazon CloudWatchでどのように設定すればいいのか、推奨設定を解説します。

Amazon EC2

CPUUtilization推奨設定：80％

EC2は、5分間でCPU使用率が80％を超えた場合をトリガーとして、スケールアップやリソースを追加することが推奨されています。そして、3回連続でしきい値を超えた場合に、担当者に通知が行くように設定をすることで、異常検知も可能です。

データ取得間隔は、5分間がAmazon CloudWatchのデフォルト値ですが、詳細モニタリングを有効にすることで、データを1分間隔で収集できるようになります。

StatusCheckFailedの推奨設定：しきい値1.0、データポイント数:2

StatusCheckFailedメトリクスは、EC2インスタンスが正常に動作しているかを確認するためのメトリクスです。EC2の基盤となるホストシステムのチェックか、EC2インスタンス自体のチェックが不合格の場合に値が1となります。

このメトリクスが2回連続で不合格の「1」が表示された場合に、インスタンスの再起動やスナップショットからの復元をすることが推奨されています。

Amazon EC2 Auto Scaling

GroupInServiceCapacity：推奨しきい値は環境によって変化

自動スケーリンググループ内で稼働中のインスタンスの数が、運用に必要な容量を下回っていないか確認するためのメトリクスです。60秒間でデータを取得し、10回の評価期間全てでしきい値を下回った場合にインスタンス数を増やすことが推奨されています。

稼働しているシステムやアプリケーションによって、必要なインスタンス数が異なりますが、必要な最小インスタンス数を計算して設定しましょう。

Elastic Load Balancing

HealthyHostCount推奨設定：2

このメトリクスは、各AZ（アベイラビリティゾーン）における正常なインスタンスの数を示します。例えば、各AZに少なくとも2つの正常なインスタンスが必要な場合、しきい値を2に設定します。

RequestCountの推奨設定：環境によって異なる

このメトリクスは、ELBを通過するリクエスト数を監視するメトリクスです。通常のトラフィック量に基づいてアラームを設定することが推奨されています。急激なトラフィックの増加はDDoS攻撃の検出、急激な減少はサービスの停止やトラフィックの逸脱を検出するために役立ちます。

Lambda

Lambdaとは、AWSが提供するサーバーレスコンピューティングサービスです。このメトリクスを使うことで、Lambda関数の同時実行数が上限に近づいているかどうか監視できます。

ClaimedAccountConcurrency推奨設定：同時実行上限の90％

Lambda関数の同時実行数は、同一アカウント、同一リージョン内で「1000」に制限されていますが、大規模システムなどで利用する場合は、上限緩和も可能です。上限に達して、システムの稼働が停止する恐れがあるため、Lambdaを使用する場合は監視設定も必ず行いましょう。

CloudFront

CloudFrontは、AWSが提供するWebサイトやアプリのコンテンツを世界中のユーザーに高速に配信するためのサービスです。

HTTPErrorRate、5xxErrorRateの推奨設定：どちらも1％

このメトリクスは、HTTPエラーまたは、5xxエラー（サーバーエラー）の発生率が上昇していることを検出します。AWS公式では、0より大きい値で設定することが推奨されています。

CacheHitRatioの推奨設定：90％

このメトリクスは、キャッシュヒット率が低下していることを検出できます。ヒット率が下がると、サーバーの負荷が上がるため設定の変更が必要です。

BytesDownloaded：環境により異なる

ダウンロードされたデータ量が急激に増加し、DDoS攻撃を受けていることを検知するためのメトリクスです。

Amazon RDS

Amazon RDSは、AWSが提供するリレーショナルデータベースの管理サービスです。自動バックアップやパッチ適用、スケーリングなどの機能を持ち、データベースの運用を簡素化します。

CPUUtilizationの推奨設定：80％

このメトリクスは、RDSインスタンスのCPU使用率を示します。EC2と同様に、CPU使用率が80％を超えると、アラームを出す設定が推奨されています。

FreeStorageSpaceの推奨設定：上限の90％

このメトリクスは、RDSインスタンスに残されたストレージ容量を示すメトリクスです。ストレージ容量が上限の90％に近づいた場合、アラームを設定して容量不足によるパフォーマンス問題やデータ損失を防ぐ必要があります。

DatabaseConnectionsの推奨設定：環境によって異なる

このメトリクスは、RDSインスタンスに接続されているデータベース接続数を表します。過剰な接続数は、データベースのパフォーマンスに影響を与える可能性があるため、環境に応じて適切なしきい値を設定することが重要です。

AWS監視を行う際の注意点

AWSで監視を行う際は、単にツールを導入するだけでなく、監視の目的や運用への影響を考慮し、効果的で効率的な監視体制を構築することが重要です。

すべてのログを取得する必要はない

すべてのログを取得することは理論上可能ですが、ログが膨大な量になったり、ログが重複する可能性が高いです。

不要なログを取り除くことで、監視業務の負荷を軽減し、より重要なデータの分析に注力できます。適切なログを選別し、取得するデータを最適化することで、分析の効率を高め、コストを抑えることも可能です。

監視システムを定期的に見直す

AWSの監視システムは、導入した時点で完了ではなく、定期的な見直しが必要です。ビジネス要件やシステム構成の変化に対応するため、メトリクスの設定やアラート条件を適宜更新し、常に最適な状態を保つことが求められます。

また、新しいAWSサービスや機能が追加された際には、それらを活用した監視の強化も考慮すべきです。

運用に負荷をかけない監視体制を取る

監視業務の目的は、運用の効率化を行うことです。監視システムが複雑化すると運用に負荷がかかり、システムの安定稼働の逆効果となります。そのため、監視ツールの設定やアラートの数を適切に管理し、過剰な監視を避けることが重要です。

軽量かつ効果的な監視体制を整えることで、リソースを無駄にせず、システム全体のパフォーマンスを維持できます。

まとめ

本記事では、AWS環境の監視におけるベストプラクティスと、CloudWatchの推奨設定について解説しました。CloudWatchの豊富な機能を活用し、適切なメトリクスを選択、アラームを設定することで、システムの異常を早期に検知し、迅速な対応が可能になります。

さらに、CloudWatch LogsやCloudWatch Insightsと連携することで、ログ分析による詳細なトラブルシューティングも実現できます。本記事で紹介した推奨設定を参考に、自社のAWS環境に最適な監視体制を構築しましょう。