概要

基本的に土日はテスト環境とステージング環境を使う事がないので、コスト削減停止しておきたい。

以前は Lambda を使ってゴニョゴニョやっていたが、正直面倒というか最近転職したのもあってやり方を失念しているので他に簡単な方法は無いかとググってみたら Instance Scheduler という便利そうなものがあったので、やり方をメモしながらやっていく。

スタック作成手順

Instance Scheduler テンプレートを利用

Instance Scheduler のデプロイオプションから「AWSコンソールで起動する」ボタンをクリック

テンプレートの選択

GitHub上のテンプレートリストから利用するテンプレートが既に選択された状態になっているので、そのまま次へ移動

スタックの詳細を指定

スタック名はスケジュールを設定したい EC2, RDS のタグ名に指定するので覚えておく。
（※今回「DevSchedule」を設定している）

パラメータ

Schedule tag key

Instance Scheduler がスケジュールを反映するために必要なタグの名前。このタグ名を持つEC2, RDS が対象となる

Scheduling interval (minutes)

Lambda を実行するインターバル時間。設定された時間が短いほどスケジュール通りに起動・停止する。
正直 EC2, RDS が5分動く場合と Lambda が100回動いたとしても圧倒的に Lambda が安いので、必要以上に下げる必要はない。というかデフォルトの5分でよい。

Default time zone

名前のまま。スケジュールのタイムゾーン。日本で動かしているサービスであれば「Asia/Tokyo」一択。

Enable scheduling

スケジュールのオンオフ。今すぐ動かすなら Yes, 仮で設定しているだけなら No

Enable EC2 scheduling

EC2 をスケジュール対象とするか。
Enabled か Disabled

Enable RDS instance scheduling

RDS をスケジュール対象とするか。
Enabled か Disabled

Enable RDS cluster scheduling

RDSのDBクラスターをスケジュール対象とするか。Aurora や RDS マルチAZが対象。
Enabled か Disabled

Enable Neptune cluster scheduling

グラフデータベースである Nepture をスケジュール対象とするか。
Enabled か Disabled

Enable DocumentDB cluster scheduling

MongoDB互換である DocumentDB をスケジュール対象とするか。
Enabled か Disabled

Enable AutoScaling Group scheduling

時間帯によって EC2 のオートスケーリングをスケジュール対象とするか。
例えば、18:00 ～ 22:00 はアクセスが増えるのでインスタンスを増やすとか。
Enabled か Disabled

Tagging

Start tags

この設定で開始されたインスタンスにタグを設定する。
無効化する場合は空白を追加。

Stop tags

この設定で停止されたインスタンスにタグを設定する。
無効化する場合は空白を追加。

Service-specific

よく分からないのでデフォルトのまま

Create RDS instance snapshots on stop

RDS 停止時にスナップショットを取得するか。
Enabled か Disabled

Account structure

よくわからないので除外

Region(s)

このスタックを適用するリージョン。現行リージョンのみでよいなら空白のまま。

Monitoring

Log retention period (days)

ログ保存期間。短くても良さそう。

Other

SchedulingRequestHandler Memory size (MB)

Lambda 関数のメモリサイズ。まぁデフォルトで良さそう。

AsgHandler Memory size (MB)

ASGリソースをスケジュールするLambda関数のメモリサイズ。
よく分からないがタイムアウトが多い場合に増やすっぽい。

Orchestrator Memory size (MB)

マルチアカウント、マルチリージョンのスケジューリングを調整するラムダ関数のメモリサイズ。
よく分からないがタイムアウトが多い場合に増やすっぽい。

Protect DynamoDB Tables

このスタックで作成される DynamoDB に削除保護を設定するかどうか。
設定しない場合、このスタックを削除すると一緒に DynamoDB も削除される。
Enabled か Disabled

スタックオプションの設定

基本的にデフォルトにした。

アクセス許可 - オプション

設定しない場合、スタックを作成したユーザーの権限を利用する

確認画面

問題なければOK

スケジュールの設定

設定値を保持している DynamoDB に移動

CloudFormation -> スタックの詳細 -> 該当のスタックを選択 -> リソースタブを選択 -> ConfigTable から該当の DynamoDB に移動できる

[タグ名]-ConfigTable-xxxxxxxxxx テーブルの確認

「テーブルアイテムの探索」ボタンを押すとテーブルの中身を参照できる

type の種類

config
schedule（利用する period を設定する）
period（起動時間や曜日を設定）

今回、下記画像のように「jp-office-hours」という名称の schedule を作成し、periods には office-hours を設定した
（※office-hours には beginTime: 17:00、endTime: 17:40 が設定されているため、17:00 ～ 17:40 の間起動するスケジュールを設定したということ）

EC2, RDS にタグを設定する

スタック名は「DevSchedule」にしたため、タグ名を「DevSchedule」とする
タグの値については、設定したい schedule の name を設定する。
今回 17:00 ～ 17:40 の間起動させたいという場合は jp-office-hours を格納する

これで、17:00 ～ 17:40 の間起動する設定を EC2, RDS インスタンスに追加できる

感想

Lambda より簡単！