Amazon CloudWatchによる複数AWSアカウントの統合監視
株式会社Fusic / 槇原竜之輔(マキッ)
チームリーダー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
ツールの利用規模 | ツールの利用開始時期 |
---|---|
10名以下 | 2023年10月 |
ツールの利用規模 | 10名以下 |
---|---|
ツールの利用開始時期 | 2023年10月 |
アーキテクチャ
アーキテクチャの意図・工夫
CloudWatch Cross Account Observabilityの機能で、複数ワークロードアカウントをソースアカウントとして設定し、それらのログやメトリクスをモニタリングアカウントで一元管理出来るような設定を行っています。
ワークロードアカウントはInfrastructure as Codeで複数展開しやすいようにしておき、システムの稼働に必要なリソースを作成する際に、同時にCross Account Observabilityの設定も行い、アカウントが大量に増加しても容易に対応出来るようにしています。
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
各アカウントでそれぞれ監視設定を行っていて、全体的な状況を把握するのに都度アカウントを切り替える手間がかかっていました。 また、各アカウントに監視メンバー用のアカウント設定を行う必要がありました。
どのような状態を目指していたか
複数のAWSアカウントにおける監視項目を一元的に管理・確認出来る状態を目指しました。
導入の成果
導入によりワークロードアカウントのメトリクス・ログをモニタリングアカウントに集約し、一括管理出来るようになりました。
これにより、重複した通知設定を省くことや監視担当者のアクセスが必要なアカウントを一つに絞ることが出来、運用面・セキュリティ面で効果があったと考えています。
導入に向けた社内への説明
上長・チームへの説明
サードパーティ製のツールを追加で導入する必要がなく、AWSのマネージドサービスでのみ完結出来るという、導入・運用の容易さがありました。
また、使用する範囲(ログ、メトリクスの共有)におきましては、追加料金が特に発生しないことも利点の一つでした。
活用方法
よく使う機能
- 各サービスにおける障害の検知
システムの障害検知に下記メトリクスの監視を設定することが多いです。
- ALBの4XX・5XXエラー、新規接続数
- EC2/ECSのCPUとメモリの使用率
- RDSのCPU使用率
- クロスアカウントオブザーバビリティ
モニタリングアカウント・ソースアカウントの設定を行い、ソースアカウントの監視項目をモニタリングアカウントに共有します。
- ダッシュボード
各監視項目やパフォーマンス状況を一元的に可視化するのに使用します。
ツールの良い点
- AWSのマネージドサービスなので導入・設定は容易
- 低コストで利用可能
- 共有後はソースアカウントからモニタリングアカウントへのログの共有が即時
ツールの課題点
- Synthetics(Canary)は共有出来ない
- 初回の共有には数分〜10分ほど時間がかかる
ツールを検討されている方へ
CloudWatch Cross Account Observabilityを使用すると、サードパーティのツールを導入しなくても容易に複数アカウントの監視が一元管理可能になります。
導入コスト・ランニングコストは低いので、複数AWSアカウントの運用をされている方には非常におすすめです。既存のアカウントに対しても簡易な操作で追加設定可能ですので、運用が始まってから一元管理の要望が発生した場合にも活用してみてはいかがでしょうか。
ただし、外形監視に使われるCloudWatch Syntheticsは現状統合出来ないので、インターネット上にサービスが公開されている場合はモニタリングアカウントでのみ設定を行い、閉域網のサービスの場合はネットワーク的にアクセス可能なようにする等、統合には工夫が必要です。
株式会社Fusic / 槇原竜之輔(マキッ)
チームリーダー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社Fusic / 槇原竜之輔(マキッ)
チームリーダー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法