re:Invent での Lab と Workshop の違い（個人的な所感）と、Lab で出会った Instance Scheduler（scheduler-cli）について

AWS CLI が好きなテクニカルサポート課の市野です。

今年の re:Invent にラスベガスでの現地参加ができることとなり、現地でさまざまなセッションに参加してきました。

基調講演のほか、Session Type が Lab とされているものと、Workshop となっているものの双方に参加しましたので、それぞれの（個人的に感じた）違いと、参加した Lab で実施した手順の中で出会った Instance Scheduler（scheduler-cli）についてまとめてみます。

Lab と Workshop の違い（個人的な所感）

正式な定義が AWS 側にはあるのかもしれませんが、両方に参加してみて以下のような違いがあるかと感じました。

lab
正式には、Self-paced Lab とされていて、会場に用意されている PC で実施します。
講師役からの 30 分程度の概要説明を受けた後、短時間の構築で終わるような、構築対象や目的を絞り込んだハンズオン
Workshop 各自参加者の PC 端末を使用。
講師役からの 30分程度の概要説明を受けた後、1 〜 1.5 時間ほどの構築作業、事後説明を受けるような、やや複雑な構成などのハンズオン

Lab での気づきと検証

参加した Lab プログラムの一つに「Secure your account during an active event」と言うものがあり、大まかに以下のようなことをやってみると言うハンズオンでした。

EventBridge の設定により、特定のインスタンス ID を持つインスタンスのステータスが stopped、 stopping、terminated となったら通知を行うための設定の実施
CloudTrail で上記事象が起きた際の確認方法について
インスタンスの停止を制限する方法、終了を削除する方法について
コストコントロールを目的とした定期的なインスタンスの停止と起動に対して、人手による作業でのミスの回避をするために、Instance Scheduler を使用した定期的なインスタンスの停止と起動を行う方法について

上記の作業手順のうち、Instance Scheduler と言うものを知らなかったので、ドキュメントの確認と検証による復習を行いました。

検証手順の概要

手順の概要は以下の通りとなります

所定の CloudFormation スタックの実行を行い必要なリソースの作成
EC2 インスタンスを作る（コストコントロールの対象）
scheduler-cli パッケージのインストール（今回は、＜1＞で作成したインスタンス自身から実施）
Instance Scheduler によるスケジュールの設定
動作確認

検証内容

1. 所定の CloudFormation スタックの実行を行い必要なリソースの作成

Architecture overview にある通り、必要なリソース群を作成するために、用意されている CloudFormation スタックを実行し、リソースを作成していきます。

なお、作業自体は、AWS マネジメントコンソールから cloudshell を利用して実施して実行しました。

変数の設定

STACK_NAME=AutoStartStopEC2
DEFAULT_TIMEZONE=Asia/Tokyo
TAGNAME_FOR_INSTANCE=AutoStartStopEC2
DEFAULT_REGIONS=ap-northeast-1

スタックの作成

リソース群の作成時にキモとなるのは、CloudFormation のオプション項目となっている TagName に設定する値、および、後続の処理での Instance Scheduler によるスケジュールの設定時のスケジュール名の設定となります。

背景として、Instance Scheduler による自動起動/停止の対象とする AWS リソースの判定が、以下のような文字列を持つタグ設定されていることが条件となるためです。

CloudFormation スタックを作成する際のパラメータとして入力した文字列をタグキーとして設定されている
scheduler-cli で create-schedule を行う際に name として付与した文字列をタグ値として設定されている

なお、StartedTags、StoppedTags、CrossAccountRoles のパラメータは指定することが必須のようでしたが、値は空で問題ないようでしたので、一旦空にしています。

aws cloudformation create-stack \
  --stack-name ${STACK_NAME} \
  --capabilities CAPABILITY_IAM \
  --template-url https://s3.amazonaws.com/solutions-reference/aws-instance-scheduler/latest/aws-instance-scheduler.template \
  --parameters ParameterKey=DefaultTimezone,ParameterValue=${DEFAULT_TIMEZONE}\
               ParameterKey=TagName,ParameterValue=${TAGNAME_FOR_INSTANCE} \
               ParameterKey=Regions,ParameterValue=${DEFAULT_REGIONS} \
               ParameterKey=StartedTags,ParameterValue= \
               ParameterKey=CrossAccountRoles,ParameterValue= \
               ParameterKey=StoppedTags,ParameterValue=

2. EC2 インスタンスの作成

作業自体は、AWS マネジメントコンソールから cloudshell を利用して実施しています。

変数の設定

INSTANCE_TYPE="t2.micro"
KEY_NAME="test.pem"
SUBNET_ID="subnet-xxxxxxxxxxxxxxxxx"
TAG_VALUE="TEST-Instance"
INSTANCE_PROFILE="arn:aws:iam::xxxxxxxxxxxx:instance-profile/AmazonSSMManagedInstanceCore"
INSTANCE_NAME="AmazonSSMManagedInstanceCore"

# 実行時の最新版の Amazon Linux 2 の AMI ID を取得
AMI_ID=$(aws ec2 describe-images \
  --owners amazon \
  --filters "Name=architecture,Values=x86_64" \
            "Name=name,Values=amzn2-ami-kernel-*" \
  --query 'Images[].[Name, ImageId]' --output text | sort | tail -n 1 | awk -F ' ' '{print $2}') \
  && echo ${AMI_ID}

インスタンスの作成

aws ec2 run-instances \
  --instance-type ${INSTANCE_TYPE} \
  --key-name ${KEY_NAME} \
  --subnet-id ${SUBNET_ID} \
  --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=${TAG_VALUE}},{Key=${TAGNAME_FOR_INSTANCE},Value=${TAGVALUE_FOR_INSTANCE}}]" \
  --iam-instance-profile Name=${INSTANCE_NAME} \
  --associate-public-ip-address \
  --image-id ${AMI_ID}

3. scheduler-cli パッケージのインストール

以下の作業は、該当の EC2 インスタンスに Systems Manager 経由でアクセスして実行しました。

# root ユーザーにスイッチ
sudo su -

# 作業用ディレクトリの作成と移動
mkdir /tmp/scheduler-cli && cd $_

# パッケージのダウンロードと解凍
wget https://s3.amazonaws.com/solutions-reference/aws-instance-scheduler/latest/scheduler-cli.zip
unzip scheduler-cli.zip

# パッケージのインストール
python3 setup.py install

4. Instance Scheduler によるスケジュールの設定

引き続き、該当の EC2 インスタンスに Systems Manager 経由でアクセスして実行した状態で実行します。

例として、期間設定を平日の営業時間を想定して設定してみます。

# 期間の設定
STACK_NAME="AutoStartStopEC2"
TAGVALUE_FOR_INSTANCE="Serverworks"
scheduler-cli create-period --name "weekdays" --begintime 10:00 --endtime 19:00 --weekdays mon-fri --stack ${STACK_NAME}

# スケジュールの作成
scheduler-cli create-schedule --name ${TAGVALUE_FOR_INSTANCE} --periods weekdays --timezone Asia/Tokyo --stack ${STACK_NAME}

5. 動作確認

前述の工程で 10:00 〜 19:00 のように、弊社の標準の業務時間を設定してみましたが、以下のような scheduler-cli update-period サブコマンドを利用して、現在時刻の 2分後を停止タイミングとして設定してみます。

その後、静観しましたが、挙動として、5分おきに、手順1 の CloudFormation スタックで作成された Lambda 関数から、所定のタグ設定を持つリソースが存在するか、および、設定されているスケジュールのチェックを行なっていました。

そのチェックで合致した自動起動/停止のタイミングを過ぎた直近の次回のチェック時に、実際の自動起動/停止が行われるため、自動起動/停止のタイミングは、実質 5分おきのタイミングで実行される仕様となっていました。

scheduler-cli update-period --name "weekdays" --begintime 10:00 --endtime $(date -d '2 minutes' +'%H:%M') --weekdays mon-fri --stack ${STACK_NAME}

まとめ

Instance Scheduler（scheduler-cli）を利用して、CLI 経由で AWS リソースの自動停止および起動の制御を行うことができ、独自実装の Lambda 関数などで、自動停止および起動の管理から解放されると見込まれます。
ただし、基本的には CLI 経由での設定となるため、うまく手順化しないとかえって煩雑になる、視覚的にわかりにくい点がデメリットかもしれません。（私のようになんでも CLI でやりたがる派にはいいのかもですが。）
なおかつ、テクニカルサポート側の目線でお伝えすると、Instance Scheduler に限らず、AWS ソリューションとして公開されている情報は、「情報提供のみを目的」としており「現状のまま」提供される形とされています。
そのため、基本的にはお客様にて評価責任を負うものとなり、該当のソリューションの実装内容自体のお問い合わせを AWS サポートおよび、AWS サポートの準じる弊社テクニカルサポート窓口でお受けできかねます点にご注意が必要です。
そのため、弊社のお客様であれば、CloudAutomator で視覚的な自動停止および起動の設定を行うことができますので、是非とも CloudAutomator をご利用いただければ、と思います。

ではまた！