Organizations環境でSystems Manager Quick SetupのResource Schedulerを試してみた

Organizations環境でSystems Manager Quick SetupのResource Schedulerを試してみた

2022.12.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは。大阪オフィスの林です。

先日のアップデートでSystems Manager Quick Setupを使ってEC2の起動/停止をスケジューリング出来るようになりました。

Organizations環境にも適用できそうでしたので、Organizations環境下で別のアカウントに対してEC2の起動/停止をスケジューリングしてみたいと思います。(本エントリでは停止のみ動作を見ていきます。)

やってみた

Systems Managerのダッシュボードに移動し「高速セットアップ」- 「Resource Scheduler」の作成を選択します。

インタンスを特定するタグとして「test1」を指定しておきます。(予め対象のインスタンスにはtest1というタグを付けています)

インスタンスの起動と停止のスケジュールをセットします。

ターゲットに停止対象のインスタンスが起動しているアカウントが所属するOUを指定します。

リージョンは特定しても良いのですが今回はすべてのリージョンを選択してResource Schedulerの設定を作成します。

複数リージョンを選択したこともあり、設定の展開に少し時間が掛かりそうなので暫く待ちます。

Resource Schedulerの設定が完了しました。

停止に設定した時間を迎えると対象のアカウント上で起動していたインスタンスが停止されました。(Organizations環境でもサクッと設定出来ました。パチパチ)

どのようなアーキテクチャで実現しているのか確認してみる

CloudTrailからイベントを確認してみると、オートメーションが動いてインスタンスの停止が行われているように見えました。

オートメーションの設定を覗いてみると起動と停止に必要そうなファンクションが幾つか作成されていました。

停止に使われたオートメーションのコードはこんな感じです。

「オートメーションを発火させるトリガーはEventBridgeなのかな?」と思いEventBridgeを見てみると予想通りEC2の起動と停止のルールが作られてました。

ここまでの状況から、Systems Manager Quick SetupのResource Schedulerでは、EC2の起動停止を処理するオートメーションの作成と、そのオートメーションをスケジュール実行するためのEventBridgeの設定をラップして設定してくれてるように見えます。

まとめ

起動停止のアーキテクチャをイチから設計・設定するとそれなりに手間なのですが、こうしてAWS側の機能でラップして実装してくれると非常に効率的に実装出来そうです。
今まで手作りのLambdaなどでEC2の起動・停止の仕組みを組み込まれていた方や、これからEC2の起動・停止の仕組みを組み込んでいきたい方は、是非Systems Manager Quick SetupのResource Schedulerの利用も検討頂ければと思います!

以上、大阪オフィスの林がお送りしました!


そのマルチアカウント運用、気合いで支えていませんか

Organizations や Control Tower で土台は作れても、アカウントもポリシーも増えるほど、運用は「詳しい一人」に寄りかかっていく。属人化が限界を迎える前に、組織として回す仕組み=CCoEへ。5,600社の支援から得た立ち上げの型を、無料資料にまとめました。

CCoE総合支援

組織で回す仕組みの資料をもらう

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事