AWSの触れ初めに手間取ったこと・疑問に感じたことのまとめ

こんにちは、井下です。

ここ最近の冷えとともに空気が乾燥してきたのか、ほぼ1日1回静電気にやられております。ドアノブに触れるのが怖いです…。

今回はAWSについてのお話になります。

ただし、堅牢なセキュリティ設計や、厳密な運用計画のように難しい話ではなく、私がAWSに触れ始めた頃に、手間取ったことや、疑問に感じたことについてのお話です。

なかでも特に手間取ったこと、疑問に感じたことを以下の4つに絞って説明していきます。

• 「無料利用枠」ってあるけど、本当に無料で使えるの？
• とりあえずAWSで仮想サーバを立てたいけど、サービスがたくさんあってどれを使えばいいのか分からない
• 作った覚えがないリソースが作成されている
• ファイアウォールの設定が効かない

「無料利用枠」ってあるけど、本当に無料で使えるの？

まずAWSの利用前に、料金はどれくらいか調べるうちに、「無料利用枠」があることに行き着く人は多いと思います。

このサービスがここまでの利用なら無料になりますよ、と提示してくれているのですが、AWSで提供しているサービス内の構成が分かっていない段階だと、理解することがかなり難しいです。

利用目的がとりあえず仮想サーバ欲しい！　くらいであれば、気をつけるのは以下の点でしょう。

• 固定IP(Elastic IP アドレス)を割り当てている仮想サーバが停止していると、停止している時間に応じて課金される
  ※ 固定IPを解放すれば課金されなくなりますが、一度解放した固定IPと同じIPアドレスを取得できるとは限りません
• 稼動させるストレージの総容量が一定以上だと、容量に応じて課金される

利用目的によって、課金されるところが変わってくるので、分かる人がいればまず相談してみるのが一番良いです。

業務利用で予算がそこまでガチガチに定まっていないのであれば、まずは使ってみてからどれくらいかかったかを見てみるのも一つの手ではあります。
AWSではどのリソースのどこで課金されているのかが見えるようになっているので、コストを抑えるための判断材料は提供されています。

AWS SDK for Rubyでインスタンスに関連づいていないセキュリティグループを削除する

こんにちは、井下です。

前回の鷲尾のブログに引き続いて、AWS SDK for Rubyを利用して、AWSの操作を行ってみます。
AWSへの操作という点では、AWS CLIと同じなのですが、SDKの場合は好きな言語で操作を行える点が魅力ですね。
なお、今回利用するAWS SDK for Rubyはv2です。導入方法・利用方法は最後に補足として説明しています。

さて、今回のテーマはタイトル通り、インスタンスに関連づいていないセキュリティグループの削除ですが、セキュリティグループはいくつ作っても課金対象ではありません。
そのセキュリティグループをわざわざSDKで削除させようとしているのは、セキュリティグループが意図せず増える土壌があるからです。

まず、EC2インスタンスを新規作成するとき、デフォルトの設定ではセキュリティグループもそのインスタンス用に新規作成・関連づけしてくれるようになっています。
ただし、EC2インスタンスを削除するときには、関連づいたセキュリティグループを削除してくれません。恐らくはセキュリティグループの仕様として、セキュリティグループ1つで複数のEC2インスタンスと関連づけが可能なためですね。

つまり、"とりあえず使える環境が欲しい"とEC2インスタンスをデフォルト設定で作成・削除を繰り返すと、使われないセキュリティグループがどんどん増えていきます。
また、セキュリティグループの一覧画面からは、EC2インスタンスに関連づいているかが見えないため(EC2インスタンス側からは、どのセキュリティグループが関連づいているかが見えます)、不要なセキュリティグループの削除には手間がかかってしまいます。

下の画像は私個人のAWSコンソールですが、EC2インスタンス4つに対し、セキュリティグループは19個もあります。15個は使われてない&今後使われることもないセキュリティグループです…。

前置きが長くなりましたが、実際にAWS SDK for Rubyを使ってインスタンスに関連づいていないセキュリティグループを削除してみます。
コードは以下のようになりました。

AWS SDK for Ruby を使って、インスタンスの一覧を取得してみる

こんにちは。

鷲尾です。

現在AWSからは様々な言語用のSDKが提供されていますが、今回はRuby用のSDK"AWS SDK for Ruby"を使って、AWS上のインスタンスの一覧を取得したいと思います。

それでは、はじめにプログラムを実行する準備からです。

１．必要なもの

RubyでAWSのインスタンス情報を取得する際に必要となるものは、以下の4つです。

・Rubyの実行環境

・AWS SDK for Ruby

・AWSアカウント（認証情報）

・リージョン情報（EC2）

※今回は実行環境としてRedHatを使用していますが、事前にRubyのプログラムを実行できる環境を作成しておいてください。

※AWSアカウント、及びIAMユーザは既に作成済みであることを前提としています。RubyでAWSにアクセスする際にはIAMユーザを作成時にのみ取得することが出来る認証情報（シークレットアクセスキー）を使用しますので、忘れずに保存してください。

なお、現在使用できるリージョンの一覧を以下に記載します。（2015年9月7日現在）

リージョン一覧（引用：http://docs.aws.amazon.com/ja_jp/general/latest/gr/rande.html#ec2_region）

Region Name	Region	Endpoint	Protocol
米国東部（バージニア北部）リージョン	us-east-1	ec2.us-east-1.amazonaws.com	HTTP and HTTPS
米国西部（オレゴンリージョン）	us-west-2	ec2.us-west-2.amazonaws.com	HTTP and HTTPS
米国西部（北カリフォルニア）リージョン	us-west-1	ec2.us-west-1.amazonaws.com	HTTP and HTTPS
欧州（アイルランド）リージョン	eu-west-1	ec2.eu-west-1.amazonaws.com	HTTP and HTTPS
アジアパシフィック（シンガポール）リージョン	ap-southeast-1	ec2.ap-southeast-1.amazonaws.com	HTTP and HTTPS
アジアパシフィック（シドニーリージョン）	ap-southeast-2	ec2.ap-southeast-2.amazonaws.com	HTTP and HTTPS
アジアパシフィック（東京）リージョン	ap-northeast-1	ec2.ap-northeast-1.amazonaws.com	HTTP and HTTPS
南米（サンパウロ）リージョン	sa-east-1	ec2.sa-east-1.amazonaws.com	HTTP and HTTPS

１．aws-sdkをインストールする

以下のようにGemコマンドを利用して、aws-sdkをインストールすることができます。

RubyでSDKを使用する場合は、非常に簡単に準備が出来てしまうのがいいですね。

なお、AWS SDK for Rubyには、"v1"と"v2"という2つのバージョンが存在します。本来はv2を使用する予定だったのですが、私の環境だとなぜかうまく動いてくれず、今回は泣く泣くv1を使用しています。そのため、今回は明示的にv1のバージョンを使用することを明記してSDKのインストールを行います。

gem install aws-sdk -v "~>1"

これでインストールは完了です。

２．Rubyのプログラムを作成する

では実際にインスタンスの一覧を取得するRubyのプログラムを作成します。

今回はインスタンスの一覧と同時に、"インスタンスのID"、"インスタンスのステータス"、"インスタンスのIPアドレス"の3つを取得してみます。

◆ aws_instance_list.rb

プログラムはこちらからダウンロード出来ます。

require 'aws-sdk-v1'

AWS.config(:access_key_id => 'アクセスキー',

           :secret_access_key => 'シークレットアクセスキー',

           :ec2_endpoint => 'リージョン')

ec2 = AWS::EC2.new

puts '#instance-id    status    ip-address'

ec2.instances.each{|instance|

  puts "#{instance.id}\t#{instance.status}\t  #{instance.ip_address}"

}

なお、処理の流れとしては、"aws-sdk"を使用するためにrequireで外部ライブラリを宣言しておき、AWS.configで認証情報を設定した後に、その認証情報をもとにインスタンス情報を取得してくるという流れになっています。

３．実行

それでは気を取り直して、作成したRubyプログラムを実行してみましょう。

プログラム修正後、プログラムを実行します。

ruby aws_instance_list.rb

実行結果：

[ec2-user@ip-172-31-40-77 ~]$ ruby aws_instance_list.rb

#instance-id    status    ip-address

i-9*******      stopped

i-a*******      stopped

i-7*******      stopped

i-5*******      running   52.**.***.**

i-e*******      running   52.**.***.**

i-5*******      stopped

このように、インスタンスID、インスタンスのステータス、インスタンスのIPアドレスを取得することが出来ました。

AWSでは基本的に実行しているインスタンスにしかグローバルIPアドレスは付与されないため、現在ステータスが"running（実行中）"のもの以外は、割り当てられていないために、表示されていません（※）。

※Elastic IPが割り振られているインスタンスであれば、ステータスが"stopped"でも、グローバルIPアドレスが表示されます。

以上、AWS SDK for Rubyを使用してAWSのインスタンス一覧を取得してくるまでの流れになります。

なお、取得できるインスタンスの情報として、今回の情報以外にも様々な情報を取得することが出来ます。

・使用できるメソッド一覧

http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/EC2/Instance.html#hypervisor-instance_method

使用する際は、ぜひ参考にしてみてください。

※v2での動作確認が出来ましたら、また報告します！

以上です。

AWSのインスタンスタイプの変更をスケジューリングしインスタンスタイプを最適化する

こんにちは、井下です。

梅雨入りしたという割には日差しの強い日が多いのですが、昨年も一昨年も同じようなことを感じていたので、梅雨とはそういうものなんだと思うようにしました。

はじめに

以前のブログでインスタンスタイプの最適化を図ろうという内容をご紹介しましたが、今回は"いつ"インスタンスタイプを上げるべきか(=スペックを上げるべきか)が分かっていて、その手順を自動化したい！というケースでの解決方法をご紹介します。

特に、決まったシーズンだけ、手動でインスタンスのスケールアップをしているという方は、有効にご活用いただけます。


構成はインスタンスタイプ変更バッチを用意し、その実行をA-AUTO 50(もしくは他のジョブ管理ツール)で制御する、下記のようにシンプルな構成です。

ここからはインスタンスタイプ変更バッチのサンプルと、A-AUTO 50への登録方法について記載します。

AWSのリソース使用状況レポートを自動生成しインスタンスタイプの最適化を図る【Excelレポート生成編】

こんにちは、井下です。

先日父の日に何を贈ろうかと考えていたところ、父からの直接のオーダーがありました。
内容は「肩たたき1時間」。…小型マッサージ機なら去年贈ったはずなんですが。

はじめに

前回はメトリクスデータの収集を行うバッチ2、バッチのデータを整形するバッチ3について説明しました。
今回はバッチ3で整形されたファイルから、Excelレポート生成を行うバッチ4について説明します。

おさらいになりますが、用意する全バッチは下表の通りです。

バッチ名	処理内容	実行周期
バッチ1	インスタンス内でデータを取得し、カスタムメトリクスとしてCloudWatchへ送信します。	1分ごと
シェル1	バッチ1のシェル版です。Linuxのカスタムメトリクスを取得・送信したい場合は、こちらを利用します。	1分ごと
バッチ2	前日分の標準メトリクス・カスタムメトリクスのデータを取得します。	日次
バッチ3	バッチ2で取得したデータをまとめ、OSSのEmbulkを利用して整形します。	月次
バッチ4	バッチ3で整形されたデータから、レポートとしてExcelのグラフを作成します。	月次

バッチ4(Excelレポート生成)

処理概要

バッチ3で整形されたファイル群を元に、Excelレポートを出力します。

パラメータ

第1パラメータ（必須） ：バッチ3で整形されたファイル群の保存先パス（※）
第2パラメータ（必須） ：バッチ3で整形されたファイル群に付与されているインスタンスID
第3パラメータ（必須） ：ファイルの出力先パス（※）

※ ブランクパスを指定する場合、パスの前後を「"」で括ってください。

リターンコード

0 ： 正常終了しました
4 ： パラメータの指定が不正
8 ： 第1パラメータで指定したパスのファイル群が不足しているか、ファイルオープンに失敗しました
12： 第3パラメータで指定したパスが存在しないか、Excelレポートの出力に失敗しました
16： Excelがインストールされていません

サンプルバッチ

AWSのリソース使用状況レポートを自動生成しインスタンスタイプの最適化を図る【メトリクスデータ収集・整形編】

こんにちは、井下です。

スマフォのカバーをつけてから2ヵ月ほど、既に傷だらけになっているので、そろそろ買い換えようかなと思っているところです。
スマフォ自体も劣化してる部分があるのですが、デザインは気に入っているので、中身だけ取り換えたいと思っています。あまりスペックのこだわりはないのですが、そういうところ考えもあってAraには期待しています。(Araで気に入るデザインが出てからの話になりますが)

はじめに

さて、前回はカスタムメトリクスのデータを送信するバッチ・シェルについて説明しました。
今回は標準メトリクス・カスタムメトリクスからデータを収集するバッチ（バッチ2）と、データを整形するバッチ（バッチ3）について説明します。

おさらいになりますが、用意する全バッチは下表の通りです。

バッチ名	処理内容	実行周期
バッチ1	インスタンス内でデータを取得し、カスタムメトリクスとしてCloudWatchへ送信します。	1分ごと
シェル1	バッチ1のシェル版です。Linuxのカスタムメトリクスを取得・送信したい場合は、こちらを利用します。	1分ごと
バッチ2	前日分の標準メトリクス・カスタムメトリクスのデータを取得します。	日次
バッチ3	バッチ2で取得したデータをまとめ、OSSのEmbulkを利用して整形します。	月次
バッチ4	バッチ3で整形されたデータから、レポートとしてExcelのグラフを作成します。	月次

バッチ2（メトリクスデータ収集）

処理概要

バッチ実行日の前日分のメトリクスデータを収集します。
なお、収集するメトリクスのデータは下記の7つです。

• CPU使用率（%）
• 空メモリー容量（MByte）
• メモリー使用率(%)
• ロードアベレージ(個)
• 仮想メモリー使用率(%)
• ネットワーク受信バイト数(Byte)
• ネットワーク送信バイト数(Byte)

パラメータ

第1パラメータ （必須）：リージョンコード
第2パラメータ （必須）：インスタンスID
第3パラメータ （任意）：ave：平均値（省略時デフォルト）
　　　　　　　　　 　　　　　max：最大値

※CloudWatchでは、収集するメトリクスデータは平均値、最大値、最小値などから選択することができます。本バッチでは、maxかaveを指定します。

リターンコード

0 ： 正常終了しました
1 ： データが0件のメトリクスがありました
4 ： パラメータの指定が不正
8 ： メトリクスデータ収集に失敗しました
12： 収集したデータ出力に失敗しました

サンプルバッチ

AWSのリソース使用状況レポートを自動生成しインスタンスタイプの最適化を図る【カスタムメトリクスデータ送信編】

こんにちは、井下です。

新人研修の講師の時期が近づいてきて、資料の見直しと更新をしていますが、1年も経つと既に古い技術になっていたり、新しい概念が出てきたりして、更新する部分が意外と多いものだとしみじみと感じています。

はじめに

さて、今回から「AWSのメトリクスを自動で収集・レポート作成し、インスタンスタイプの最適化を図る」というテーマで3回ほどブログを掲載することを予定しています。

意識されている方は多いと思いますが、EC2インスタンスの課金体系は基本的に 稼働時間 × インスタンスタイプ になっています。
つまり、できるだけ使わない時間は動かさずに、できるだけ無駄のないスペックのインスタンプタイプを選択することが、コストの最適化に繋がるということになります。

稼働時間に関しては、先月書いたインスタンスの起動・停止の自動化によって、無駄を省けるようになると思いますが、インスタンプタイプはどうでしょうか？

個人利用や検証であれば、最小のmicroインスタンスを利用しても問題は起きにくいですが、外部公開したり、業務に直結するインスタンスであれば、どれを選ぶか吟味しなくてはなりません。
また、インスタンスタイプを選択した後になってから、当初とは事情が異なってスペックが足りなくなったり、持て余してしまうことも考えられないことではありません。

インスタンスタイプが適切であるかを判断するためには、CPU使用率やメモリ使用率などのリソースの状況を確認すると思います。
また、リソースの状況は一時的なものではなく、例えば1日のリソースの監視結果など、ある程度の期間のものを確認したくなるのではないでしょうか。

そんな要望に応えるサービスとして、AWSから「CloudWatch」というサービスが提供されています。

実はインスタンスを作成すると、自動でCloudWatchが次の10個の項目について監視を開始しており、その結果はAWS マネージメントコンソールから確認することができます。（監視する項目は「メトリクス」と呼びます）

• CPUUtilization(CPU使用率)
• DiskReadOps(ディスク読み取り回数)
• DiskWriteOps(ディスク書き込み回数)
• DiskReadBytes(ディスク読み取りバイト数)
• DiskWriteBytes(ディスク書き込みバイト数)
• NetworkIn(ネットワーク受信バイト数)
• NetworkOut(ネットワーク送信バイト数)
• StatusCheckFailed_Instance(過去1分のインスタンスステータスチェックの成功可否)
• StatusCheckFailed_System(過去1分のシステムステータスチェックの成功可否)
• StatusCheckFailed(「StatusCheckFailed_Instance」と「StatusCheckFailed_System」の組み合わせ)

ここまで聞くと、「それじゃあ、気になったときにCloudWatchを確認すればいいじゃないか」と思うかもしれませんが、2つ問題があります。

1つ目は、例えばインスタンスのメモリ使用率を確認しようとしても、CloudWatchのメトリクスとして監視されていないので、メモリ使用率を確認することができません。
2つ目は、CloudWatchで保持できるデータは過去2週間までになっていることです。長期間や過去の実績をAWSマネジメントコンソールから確認することはできません。

それらの問題に対しては、AWSから提供されているCloudWatch用のコマンドラインツール「CloudWatch Command Line Tools」を使うことによって解決します。

「CloudWatch Command Line Tools」では、主に記録されている各メトリクスのデータ取得および、利用者側独自に定義するメトリクス（カスタムメトリクス）のデータを送信（記録）することができます。

1つ目の問題に対しては、監視対象となる環境から何らかの方法でデータを取得し、CloudWatchにカスタムメトリクスとして送信（記録）することで、AWS マネージメントコンソールから送信された独自のカスタムメトリクスのデータを確認することができます。
2つ目の問題に対しては、日次でデータを取得（エクスポート）することで、過去のデータを保管することができます。

今回から3回に渡って、「CloudWatch Command Line Tools」とA-AUTO 50、またOSSのEmbulkを利用して、1月分のメトリクスを自動で収集・レポート作成し、インスタンスタイプの見直しに活用できるようにします。

今回、収集・レポート作成の対象とするメトリクスは以下の7つとしています。

メトリクス	単位	メトリクスの種類
CPU使用率	%	標準メトリクス
空メモリー容量	Mbyte	カスタムメトリクス
メモリー使用率	%	カスタムメトリクス
ロードアベレージ	個	カスタムメトリクス
仮想メモリー使用率	%	カスタムメトリクス
ネットワーク受信バイト数	Mbyte	標準メトリクス
ネットワーク送信バイト数	Mbyte	標準メトリクス

全体的の構成図は次のようになります。

バッチとしては5つ（バッチ1のシェル版として、シェル1を用意しています）作成し、各々が決められた周期で実行することで、Excelレポートを自動生成できます。

各バッチの処理は下記のようになっています。

バッチ名	処理内容	実行周期
バッチ1	インスタンス内でデータを取得し、カスタムメトリクスとしてCloudWatchへ送信します。	1分ごと
シェル1	バッチ1のシェル版です。Linuxのカスタムメトリクスを取得・送信したい場合は、こちらを利用します。	1分ごと
バッチ2	前日分の標準メトリクス・カスタムメトリクスのデータを取得します。	日次
バッチ3	バッチ2で取得したデータをまとめ、OSSのEmbulkを利用して整形します。	月次
バッチ4	バッチ3で整形されたデータから、レポートとしてExcelのグラフを作成します。	月次

※掲載するバッチファイル内のCloudWatchやEmbulkは2015年5月現在のインターフェースを基に記載しています。提供元でインターフェースが変更されるとことがありますので、最新の情報は各提供元でご確認ください。

今回はバッチ1・シェル1について説明し、バッチ2、3、4については後日のブログにて説明します。

AWS EC2インスタンス起動・停止自動化によるコストの最適化【自動化編】

こんにちは、井下です。
本日は、集中連載企画の第3回目【自動化編】となります。

前回のあらすじ
●　ステータス確認、起動・停止、Elastic IPの関連付けといったAPIを実際に実行してみる
●　インスタンスの起動・停止バッチを作成し、そのバッチで実際にインスタンスを起動・停止してみる

※ 過去のブログはこちらをご参照ください。
　　第1回 準備編

　　第2回 API利用編

今回は集中連載企画の最終回ということで、いよいよA-AUTO 50でインスタンスの起動・停止のスケジュール、実行を自動化し、最適化を図ります。


今回のAgendaは次のとおりです
  9．カレンダーの作成
　9.1 年間定休日を定義する
　9.2 カレンダーを作成する
10．スケジュール情報の登録
11．ジョブネットワーク情報の登録
12．ネットワークスケジュールの作成
13．バッチファイルの配置
14．インスタンスの起動・停止の監視


では、さっそく説明に入っていきますが、以降の説明は、既に基本ライセンスのインストール手順に従って、インストールが完了している前提で話を進めます。
このため、予めインストール手順に従ってインストールを完了させておいてください。

・ Webクライアントにログインできる状態にある
・ 監視ウィンドウのテンプレートを作成済みで監視画面が表示できる状態にある
・ 動作確認まで完了している

９．カレンダーの作成
はじめに、お客様独自の営業日カレンダーを作成します。

先ずは、カレンダー作成を考えるにあたり、いつが休みかを決めていきます。
一般的な休みの種類は、大きく以下の3つに分類できると思います。

（a） 週間定休日 ： 毎週土曜日や毎週日曜日といったように毎週繰り返しやってくる休日
（b） 年間定休日 ： 国民の祝日など毎年繰り返しやってくる休日
（c） 不特定の休日 ： 会社固有の休日
　　　　　　　　　　　　　例えば、夏季休暇や年末年始休暇、GWを大型連休にするために
　　　　　　　　　　　　　休みを振り替えたりすることがあると思います。
　　　　　　　　　　　　　※ 年末年始休暇などは、企業によっては毎年期間が同一だったりもしますね


次にA-AUTOのカレンダーを作成するうえでの休日の種類は次のようになります。

（ｱ） 週間定休日 ： 毎週土曜日や毎週日曜日といったように毎週繰り返しやってくる休日
（ｲ） 年間定休日 ： 毎年n月n日と言うように日付が固定され毎年やってくる休日
　　　　　　　　　　　　元旦（1月1日）、建国記念日（2月11日）などがこれに相当します
　　　　　　　　　　　　また、年末年始休暇が毎年12月29日～1月4日と固定されているようであれば、
　　　　　　　　　　　　これも年間定休日として考えます
（ｳ） 不特定の休日 ： ハッピーマンデーや春分の日、秋分の日といった毎年日付が変わる国民の休日や、
　　　　　　　　　　　　夏季休暇、GWの連休設定など、月日で固定化できない休日がこれに該当します

先ずは、一般的な休みの種類とA-AUTOの休日の種類で若干異なる部分があることが分かっていただけたかと思います。
※ 現時点でA-AUTOでは、”毎年n月のn週目のn曜日”といったハッピーマンデーには未対応としているため、不特定の休日に分類します




9.1 年間定休日を定義する
先ずは、A-AUTOの休日の考え方のうち（ｲ）の年間定休日を登録します。
年間定休日は、マスタメンテナンスメニュー［ホリデー］－［休日］を選んで表示される［休日定義一覧］から登録します。

A-AUTO 50をインストールした状態では、日付固定の国民の休日は予め登録してあります。
このほかに会社固有の年間定休日があれば、はここで登録してください。

　　※ 旧 日付固定の国民の休日も登録されているので、不要でしたら削除してください

会社固有の年間定休日は、［新規登録］ボタンをクリックして登録します。

”日付”フィールドで月日を入力または選択してください。
下記のサンプル画像は、「1月2日」を登録しています。”コメント”フィールドに「年末年始休暇」など後から見て分かるようなコメントを入れておくとよいです。

なお、［振り替え］チェックボックスがありますが、指定した日付がカレンダー上休日の日曜日であった場合、休日を翌日に自動振り替えするか否かを選択するためのものです。
※ 上記サンプル画像では、会社固有の休日であるため［振り替え］の設定は行っていません

下の画像は、同様に「1月3日、1月4日、12月29日～12月31日」も休日として定義した後の画像となります。

※ ［振り替え］を行う設定をしている休日は、一覧表示をしたときに、日付の右横にアイコンが表示されます

9.2 カレンダーを作成する
お客様固有のカレンダーを作成します。
カレンダーは、マスタメンテナンスメニュー［ホリデー］を選んで表示される［ホリデー定義一覧］から登録します。

AWS EC2インスタンス起動・停止自動化によるコストの最適化【API利用編】

みなさんこんにちは。
鷲尾です。

本日は、短期集中連載企画の第2回目【API利用編】となります。

前回までのあらすじ

●　ローカル環境に Amazon EC2 API Toolsを導入
●　インスタンスの操作に必要となる情報を収集し、環境変数を設定するバッチファイルを作成
●　作成したバッチファイルとec2ver”コマンドでAmazon EC2 API Toolsが利用できることを確認

今回は「API利用編」ということで、インスタンスのステータスの確認、インスタンスの起動・停止が行えることを確認し、最終的に起動・停止用のバッチファイルの作成・実行まで行っていきます。

※なお、コマンドは各環境変数に値がセットされていないと実行することが出来ないため、ここでは、前回作成した環境変数設定バッチ（envSetup.bat）を実行した状態（環境変数に値がセットされている状態）であることを前提としています。

６．インスタンスのステータス確認

先ずは、ターゲットとするインスタンスIDの操作が行えることを確認するために、特定インスタンスのステータスを取得します。

ステータスを確認する場合は、以下のコマンドを使用します。

ec2-describe-instances インスタンスID

コマンドを投入したときの表示は以下のような表示となります。

■起動時

ここまでくれば、もうAPIでの起動・停止ができたも同然です！

７．インスタンスのStart・Stop

次は、いよいよインスタンスの起動・停止を制御してみます。
それでは、停止状態にあるインスタンスを再起動（Start）させてみましょう。

再起動させる場合は、以下のコマンドを使用します。

ec2-start-instances インスタンスID                                                                    

startコマンド投入サンプル

 　　　　　※ i-XXXXXXXXには、実在するインスタンスIDを指定してください

今度は、起動しているインスタンスを停止（Stop）させてみます。

停止させる場合は、以下のコマンドを使用します。

 ec2-stop-instances インスタンスID       

stopコマンド投入サンプル

これで、APIからインスタンスの起動・停止が行えるようになりました！

なお、起動・停止用のAPIは、非同期処理となっています。このため、ec2-start-instances ／ec2-stop-instances から処理が戻された時点で、指定したインスタンスの起動・停止は完了していません。
このため、ec2-start-instancesとec2-stop-instancesを利用した場合、正しく起動・停止したかは、前述のec2-describe-instancesコマンドなどを利用して確認する必要があります。

８．Elastic IPアドレスの関連付け（EC2 Classicの場合のみ）

EC2（Classic）では、インスタンスを停止するとその時点で、インスタンスとElastic IPの関連付けが解除されてしまいます。

このため、停止・起動の自動化を行う場合、インスタンス再起動後に再度Elastic IPの関連付けを行う必要があります。

Elastic IPの関連付けには、以下のコマンドを使用します。

ec2-associate-address -i インスタンスID Elastic IP

※Amzon EC2 VPCの場合は、インスタンスを停止してもElastic IPアドレスは開放されません。

９．起動・停止用バッチファイルを作成・実行してみる

インスタンスを起動・停止するためのバッチファイルを作成します。
ここでは、起動および停止バッチをインスタンス毎に作成しないよう、1つのバッチファイルを共用する前提でバッチファイルのパラメータを定義します。

【起動バッチ ： ec2start.bat】

起動バッチのサンプルはこちらからダウンロード出来ます。
作成するバッチの概要は以下のとおりです。

◆パラメータ

1つのバッチファイルで複数のEC2インスタンスを起動するバッチとするため、パラメータを3つ用意します。

第1パラメータ ： リージョンコード （必須）

第2パラメータ ： インスタンスID  （必須）

第3パラメータ ： Elastic IP　　　　 （任意）

※EC2 Classic環境で、Elastic IPアドレスの関連付けをする前提としているため第3パラメータを用意していますが、EC2 VPCであれば停止後にインスタンスとElastic IPアドレスとの関連付けが解除されないので第3パラメータは不要です。

◆リターンコード

  0 ： インスタンスの起動に成功した

  1 ： 起動しようとしたインスタンスIDが既に起動しているため、処理を中止した

  4 ： 必須パラメータが入力されてない

  8 ： インスタンスへの接続に失敗した

12 ： Elastic IPアドレスの関連付けに失敗した（起動バッチのみ）

16 ：インスタンスの起動に失敗 した

第3回の自動化編では、リターンコードが0、もしくは1であれば正常とみなすように設定します。

AWS EC2インスタンス起動・停止自動化によるコストの最適化【準備編】

みなさんこんにちは。

今年の新人のフレッシュな声を背中で聞きながら、しみじみ過去の１年間を回想している鷲尾です。


さて、みなさん「AWS」はご存知ですよね。

AWSを利用すると、アマゾンが提供する環境に「Linux」や「Windows」といったさまざまなOSを「インスタンス」という形で、仮想的に利用することができます。
例えば「AWS上にCentOSなどのサーバ向けOSのインスタンスを用意し、そのサーバ上でWebサイトを運営する」といった使い方ができます。

非常に便利なAWSですが、気になるサービス利用料は「使った分だけの従量課金」となっています。つまり、「インスタンスを起動している間は料金がチャージされ、停止している間は料金は掛からない」というわけです。


であれば、少しでもインスタンスの起動時間は短くしたい（コストを抑えたい）ですよね。
しかし、毎日手動でインスタンスを起ちあげては停止し、また起ちあげて・・・ということを繰り返すのは大変ですし、オペレーションミスが発生するかもしれません。

また、「会社の営業日だけ起動させたい」、「営業時間の間だけ」、「今週は起動したくない」といったインスタンス操作のタイミングが不規則で複雑な場合、すべて手動で管理するのはさらに大変です。


そこで、強力なスケジューリング機能をもった無料の「A-AUTO 50」と「Amazon EC2 API Tools」を連携させてインスタンスの起動・停止をすべて自動化し、インスタンス起動日時をより細かくコントロールすることでコストを削減してしまいましょう！というのが今回のテーマです。

『cronやタスクスケジューラでできるでしょ！』と思われる方もいらっしゃると思いますが、連載を読み終えていただければ違いがわかっていただけると思います。

AWSとA-AUTO 50連携イメージ

すべてを１回で書ききるにはボリュームがあるので、全3回の短期連載とします。

第1回：準備編
第2回：API利用編
第3回：自動化編


 なお、本連載で使用する環境は、弊社内のWindows Server 2008R2環境からAWS上のRed Hatのインスタンスの起動・停止を行います。

使用するOS（AMI）は以下のとおりです。

・接続元（社内ローカル環境）

Windows Server 2008R2

・接続先（AWS上）

Red Hat Enterprise Linux 7.1 (HVM)：ami-4dbf9e7d

※AMIというのは、インスタンスの元になったOSイメージのことです。例えばRedHatのインスタンスを作成するときはRed HatのAMIからコピーして作成します。

ということで、ここから第1回の「準備編」の内容に入っていきます。

■準備編

インスタンスの起動・停止を制御するためには、インスタンスをAPIで操作するためのコマンドラインツール「Amazon EC2 API Tools」、インスタンスを起動・停止するそれぞれのバッチファイルと、その他AWS関連の登録情報が必要です。

※注意
本投稿での「起動」という用語についてですが、便宜上“停止状態にある既に生成済みのインスタンスを再開（Start）させること”を「起動」と記載させていただきます。

なお、正式なAWSの用語は以下のとおりです

　・ インスタンスの起動（run）    　    AMIから新しいインスタンスを生成・起動する
　・ インスタンスの停止（stop）  　    起動中のインスタンスを停止する
　・ インスタンスの再開（start）        停止中のイスタンスを再び起動する

　・ インスタンスの削除（terminate） インスタンスの起動で生成したインスタンスを削除する

ということで、第1回目の目標は、「Amazon EC2 API Tools 」を利用できるようにする所までです。

それでは以下の順に説明していきます。

1.　Amazon EC2 API Toolsとは
2.　Amazon EC2 API Toolsのダウンロード
3.　Amazon EC2 API Toolsのインストール
4.　Amazon EC2 API Toolsを使用するための準備
-　　4.1　事前に準備しておく情報一覧
-　　4.2　設定する環境変数の設定
5. Amazon EC2 API Toolsの動作確認