CloudWatchダッシュボードを別アカウントへコピーする方法｜JSON移行後に確認する参照先

AWSアカウントの移行で、手作業で作ったCloudWatchダッシュボードを一から作り直す必要はありません。ダッシュボードのJSONを取り出し、移行先で登録すると、ウィジェットや配置を再利用できます。

ただし、コピーできるのは表示の定義です。メトリクスの履歴、ログ、アラームそのものが一緒に移るわけではありません。画面をコピーした後に、どのアカウントのどのリソースを見るかを合わせることが移行の要点です。

移すものはDashboardBodyというJSON

ダッシュボードのウィジェットと配置は、DashboardBodyというJSON形式の文字列で表されます。GetDashboardで取得し、移行先の認証情報でPutDashboardへ渡すとコピーできます。これはGetDashboardの公式資料でも案内されている方法です。

少数ならコンソール、繰り返すならAPIを使う

ダッシュボードが一つか二つなら、コンソールでソースをコピーする方法が扱いやすいでしょう。移行元のダッシュボードで「アクション」から「ソースの表示／編集」を開き、JSONを保存します。移行先では別名のダッシュボードを用意し、編集したソースを設定します。

複数の環境へ展開する場合は、GetDashboardとPutDashboardを使う方法が向いています。元のJSON、移行先向けに修正したJSON、変更内容をファイルで残すと、再実行やレビューがしやすくなります。どちらの方法でも、最初に元の定義を保存しておきます。

PutDashboardは同じ名前のダッシュボードが存在すると、内容全体を置き換えます。初回は既存の監視画面と重複しない名前で作成し、確認後に運用へ組み込むと安全です。ダッシュボード自体はアカウント内でグローバルなリソースなので、リージョンを変えれば同じ名前でも別物になる、と考えないようにします。PutDashboardの仕様を参照してください。

コピー前に直すのは、見た目より参照先

例えば、移行元EC2のCPU使用率を表示するグラフには、ディメンションとして移行元のInstanceIdが入っています。移行先で新しいEC2を作った場合、そのIDへ変更しなければ期待したデータは出ません。

次の表を使って、ウィジェットごとに確認します。すべての項目が必ず存在するわけではなく、利用しているウィジェットに応じて調べます。

アカウントIDを一括置換するだけでは、リソースIDやロググループ名までは揃いません。逆に、意図して別アカウントを監視する設定まで書き換えると、必要な表示が失われます。各ウィジェットの目的を確認してから変更します。項目の意味はDashboard Bodyの構造と構文で確認できます。

移行元のデータを見続ける場合は別の設計になる

「移行先で新しいシステムを監視したい」のか、「監視するアカウントだけを変更して旧環境を見たい」のかで作業は異なります。後者では、JSONのコピーに加えて、クロスアカウントでデータを参照するための設定と権限が必要です。ダッシュボードを保存できる権限と、その中のデータを読める権限を分けて確認してください。

過去ログを残したい場合も、ダッシュボードの移行とは別に計画します。CloudWatch Logsの別アカウント移行では、過去ログの保管と今後の集約を整理しています。

完了判定は、保存成功ではなく実際の表示で行う

1. 移行先の利用者と同じ権限でダッシュボードを開く。
2. 表示期間を、移行先リソースが稼働している期間に合わせる。
3. 主要なグラフを、対象リソースのメトリクス画面と照合する。
4. ログのクエリが実行でき、アラームが意図した対象を示すか確認する。
5. 運用で使うリンクと、修正したJSONの保存先を確認する。

PutDashboardの応答にあるDashboardValidationMessagesも確認します。警告だけならダッシュボードが作成されても、一部の要素が表示されない場合があります。また、構文に問題がなくても参照するメトリクスにデータがなければグラフは空になるため、画面上の確認が欠かせません。

移行後のダッシュボードをコードで管理するなら、以後の修正をJSONへ反映する運用に揃えると、再配置時にコンソール上の変更が消える事故を避けやすくなります。

関連する記事

• CloudWatchメトリクスを長期保存する方法：表示設定とデータの保持を分けて考える際の参考になります。
• ACM証明書の別アカウント移行：Web基盤をアカウント間で移す場合の証明書準備も確認できます。