AWSのITコストを削減 Simpline

選ばれ続けること

 

エンジニアブログ

ホーム - エンジニアブログ - すべて

1 / 2312345...1020...最後 »

[AWS]Athenaについて(その3 パーティション編)

2018.08.09

お世話になっております。pinocoです。


前回、S3上のデータファイルに対しAthenaでクエリを投げるところまでやりました。


今回はパーティションについて見て行きたいと思います。


1.Athenaのパーティションについて


データのパーティション分割



データをパーティション分割することで、各クエリでスキャンするデータの量を制限し、パフォーマンスの向上とコストの削減を達成できます。Athena では、データのパーティション分割に Hive を使用します。すべてのキーでデータをパーティション化できます。



らしいです。


みなさんどうです?この一文でどの程度、わかりましたでしょうか?


ちなみに私の絶望的な理解力では「便利がいいんだな」くらいでした。


それだけ書いて投稿して本件についてはCaseClose、塩漬けにする、と言う選択肢も


浮かばなかったといえば嘘になりますが


そうしてしまうとブログとして成り立たっていないばかりか


私は社内で石を投げられてしまいます。小石と言うには大きいほどの。


なので掘り下げるしかありますまいて。


2.実際にやってみる


何もない私には、この手しか残っていないわけで、


まずはやってみて、経過や結果から知識と徳を積んでいくスタイルです。


で、紆余曲折を経てなんとかなったわけなんですが、


混乱をもたらさないように先に結果を書いておきます。



(1).  AtheneにおけるパーティションはS3上のデータをprefixで分割し、

      その下にデータを分散配置させたものを認識させることで利用できます。

   Hive形式で作成する場合だと[カラム名=値]と言う感じでS3のprefixを分割して行きます

      e.g. s3://some-bucket/year=2016/some-data-file

                                           /year=2015/some-data-file

  このカラム名(上記例の場合year)がパーティションを切るためのキーとなります。


(2). パーティション分割に利用したキーはクエリを投げる際、

   対象のテーブルのカラムとして認識されます

        また(4)で触れますが基本的にWhere句に利用するカラムとなるため、

        多く発行されそうなクエリからWhere句に利用されそうで、


   かつなんとなく均等に分散され、スキャン時データサイズが大きくなりすぎない値を

         パーティションに利用するキーとして選定すると良いと思います。ものすごく漠然としてますが。


(3). 上記(2)よりクエリを投げようと思っているデータ内

   (と言うかそこから作ろうとしているテーブル)に、

   存在するカラム名はパーティションのキーとしては利用できません。

   (※)すごくわかりづらくてすみません。後続で補足します。


(4). パーティション作成で利用したカラムをWhere句で利用することにより、

  S3のPrefixを限定したデータ走査が可能になります。

  逆をいえばパーティションとして指定したカラムをWhere句で利用しない場合、

  パーティションを切ってようが、いまいが


  テーブルとして読み込む際に全ファイルを走査します。



どうでしょう?自分の言語能力を疑いますね。まあ疑わしいのはそこだけではないのですが。

ではどういう感じでパーティションを作っていったのかを説明して行きたいと思います。

(1).データを分割しS3にputする

前回利用したTop Baby Names in the USは以下のような形式のCSVファイルです。

こんな感じの中身です。


"state","gender","year","name","occurences"
"AK","F","2012","Emma","57"
"AK","M","2012","James","51"
"AL","F","2012","Emma","317"
・・・


これを「year」で分割してHive形式でS3にあげてあげたいので、

こんな感じで処理しました。csvに対するクエリ発行はqを利用しました。

put時のprefixは"year=xxxx"としています。


#!/bin/bash

input_fname=TopBabyNamesbyState.csv
if [ ! -e $input_fname ]; then
echo "[ERROR]:InputFile not Exist"
exit 1
fi

if [ ! -e output ]; then
mkdir output
fi

y_ar=`q -H -d ',' "select distinct year from TopBabyNamesbyState.csv"`
for i in $y_ar; do
q -H -d ',' "select * from $input_fname where year = '$i'" > ./output/$i.csv
aws s3 cp ./output/$i.csv s3://xxxxxxxx/year=$i/
done


一応、レコード数的にはあってそうなことも確認しておきます(差分1行はヘッダ分)

$wc -l ./TopBabyNamesbyState.csv && wc -l ./output/*.csv | grep total

10507 ./TopBabyNamesbyState.csv

10506 total

$

 

これで、S3側は"year=xxxx"でprefixが切られ、その配下にはyear=xxxxに該当する分割したcsvの

データが格納されている状態になりました。

(2).テーブルを作成する

その上で、以下クエリを発行し、「year」を使ってパーティション分割しようとしました、が

「year」カラムが通常のカラムと、パーティションカラムとで重複し、以下例外で怒られます。

FAILED: SemanticException [Error 10035]: Column repeated in partitioning columns

つまり以下のクエリはハイライトしたカラムが重複してるよ、と言う状態。


CREATE EXTERNAL TABLE IF NOT EXISTS test.test2 (
`state` string,
`gender` string,
`year` int,
`name` string,
`occurences` int
) PARTITIONED BY (
year int
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = ',',
'field.delim' = ','
) LOCATION 's3://xxxxxxxx/'
TBLPROPERTIES ('has_encrypted_data'='false')


ここで、初めてパーティションカラムはクエリ投げる側から見た場合、

普通のテーブルのカラムと同じ位置にいるのだ、と認識しました。

なので、以下の様にカラム名が重複しない様修正しテーブルを作成しました。

CREATE EXTERNAL TABLE IF NOT EXISTS test.song2 (
`state` string,
`gender` string,
`ys` int,
`name` string,
`occurences` int
) PARTITIONED BY (
year int
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES (
'serialization.format' = ',',
'field.delim' = ','
) LOCATION 's3://xxxxxxx/'
TBLPROPERTIES ('has_encrypted_data'='false')

テーブル作成後は以下を同じ様にコンソールから実行しパーティション内のデータをロードするとあります。


MSCK REPAIR TABLE song2


以下がresultとして出力されていたので、処理としてはHiveで利用するmetastoreにパーティションの対応情報を突っ込んでいる感じでしょうか。


Partitions not in metastore:
~ snip ~
Repair: Added partition to metastore song2:year=1910
Repair: Added partition to metastore song2:year=1911
~ snip ~
Repair: Added partition to metastore song2:year=2011
Repair: Added partition to metastore song2:year=2012

ちなみにテーブル名はこの検証やってる時に社内に流れていたblurの曲名をつけてます。



果てしなくどうでもいいインフォメーションでした。


(3).パーティションは効いているのか?確かめる



では実際に確かめて見ましょう。


まずはパーティションを設定していない1つのCSVファイルに対しクエリを投げて見ます。


結果:RunTime:1.55 sec,  DataScanned 225.32KB


フルスキャンしてますね。



では次にパーティションで分割してるファイルにクエリを投げます。


結果:RunTime:1.95 sec,  DataScanned 2.06KB


ん?RunTimeがさっきより長くなっとる気がします。


これはきっと小さいファイルを扱っているからパーティション処理周りのオーバーヘッドが


パーティション分割によるファイルスキャンの最適化の恩恵を上回ったのかなと、


大きいファイルにしたらいい線で改善するのでは、と勝手に推測しました。


ちなみにスキャンしたデータ量は100分の1程度でした。


1910年〜2012年のデータを年単位で分割したので、だいたい想定通りだと思います


パーティション効いてますねー



最後のパターンはパーティション分割済みのテーブルで「パーティションに使用したキー(カラム)をWhere句から外した」


パターンをやってみたいと思います。


結果:RunTime:2.89 sec,  DataScanned 215.07KB


遅い上に全スキャンと言うなかなか香ばしい結果でした。


一番最初に実施した検証より7KB程少ないのですが、何処へ出かけたかはわかりません。



 


これで、Athenaのパーティションについての検証は終わりにしたいと思います。


今回のケースだと既に存在するファイルを取り回して検証しましたが、


ユースケース的にはログ解析とか多そうなので、そっち方面も時間があれば触ってみたいと思います。


次は、putするファイル形式で早くなるのか、とGlueでどう楽になるのか、についてを


お送りしたいと思います。

[AWS]AWS Configでルール違反検知 その2

2018.08.08

こんにちは。

middleと申します。


前回に引き続き、壁の話をお送りしたいと思います。

どうぞよろしくお願いいたします。


 


★今回のお題


セキュリティグループの開けてはいけないポートを開けてしまった時、検知したい


その1 背景〜使用するサービス選択

その2 AWS Configとは ←本日はこちら

その3 カスタムルール作成①

その4 カスタムルール作成②

その5 AWS Config設定〜まとめ


 


★AWS Configとは



AWS Config は、AWS リソースの設定を評価、監査、審査できるようにするサービスです。Config では、AWS リソースの設定が継続的にモニタリングおよび記録されるため、必要な設定に対する記録された設定の評価を自動的に実行できます。Config を使用すると、AWS リソース間の設定や関連性の変更を確認し、詳細なリソース設定履歴を調べ、社内ガイドラインで指定された設定に対する全体的なコンプライアンスを確認できます。これにより、コンプライアンス監査、セキュリティ分析、変更管理、運用上のトラブルシューティングを簡素化できます。



公式サイトより引用)


AWSリソースの設定をルールに基づきチェック(評価)してくれるサービスということで、まさに今回のお題にうってつけです。

ルールに則している場合は「準拠」、反対にルールに違反している場合には「非準拠」と評価されます。


そしてそのルールですが、あらかじめAWS側で用意されている「マネージドルール」と、自分で作成する「カスタムルール」の2種類にわかれます。

「セキュリティグループの開けてはいけないポートが開いていない」というルールはマネージドルールとして用意がないので、これをLambdaで作成する必要がある、というわけです。


また、カスタムルールと一口に言っても、フォーマットがありほとんどデフォルトで使えるようなものもあれば、一から書かないといけない場合もあります。

残念ながら今回は後者です。


ただ、githubで参考になりそうなものがいくつか公開されています。


これらを拝見してどうにかすれば、きっとカスタムルールくらいちょちょいのちょいでしょう。


 


★ルールの流れ


githubで拝見したルールを参考に、こんな感じで考えました。




開けていいポート定義




削除済みリソース

→ルール適用の対象外にする




セキュリティグループ以外のリソース

→ルール適用の対象外にする




開いているポート範囲が「すべて」だった場合

非準拠 ※要検討




開いているポートが、開けていいポート(①で定義したポート)に該当しなかった場合

非準拠




それ以外

準拠


上記の通り、「開けていいポート」以外が開いていたらNG、というカスタムルールを作ります。

実のところgithubに「開けてはいけないポート」が開いてたらNG、というルールがあったのですが、私のこだわり(後述)でこちらを利用するのはやめたのでした。


②に関しては、参考にしたものがこのように削除済みリソースについての評価を入れていたので、真似です。

(検証はしておらず憶測で恐縮ですが、削除済みリソースも評価されてしまうのではないかと)


④に関しては次回記載します。


 


★こだわり(余談)


「開けてはいけないポート」と「開けていいポート」の数を比較した場合、圧倒的に前者が多いことが予想されました。


例えば現在80番ポートのみ開けていいとしたら、「開けてはいけないポート」は「0番〜79番」、「81番〜65535番」です。


ここで仮に、「22番ポートも開けてOK」となった場合どうでしょう。


「開けてはいけないポート」は「0番〜21番」、「23番〜79番」、「81番〜65535番」になります。



★開けてはいけないポートの遷移


開けていいポートが「80番」の時

→「0番〜79番」、「81番〜65535番


開けていいポートが「22番と80番」に変更された時

→「0番〜21番」、「23番〜79番」、「81番〜65535番



めんどくさい……(私だけでしょうか)

つまり運用(ポート定義)が煩雑? になってしまうという懸念です。


個人的な感覚ですが、「開けていいポート」が「80番」から「22番と80番」になる方が、圧倒的に楽だと思ったわけです。



★開けていいポートの遷移


開けていいポートが「80番」の時

→「80番


開けていいポートが「22番と80番」に変更された時

→「22番と80番



言ってしまえば好みです。


 


★言語選択


AWS Lambdaで関数を書くにあたり、8月8日現在、以下の言語に対応しています。


・Node.js

・Python

・Java

・C#

・Go



Q: AWS Lambda がサポートする言語は何ですか?


AWS Lambda では、Node.js (JavaScript)、Python、Java (Java 8 互換)、C# (.NET Core)、および Go で記述されたコードがサポートされています。ネイティブライブラリも含め、コードには既存のライブラリを含めることができます。詳しくは、Node.js、Python、Java、C#、および Go の使用に関するドキュメントをご覧ください。



公式サイトより引用)


今回はPythonを選択してみました。

どうせどの言語も未経験なのでこの際何でもOKなのですが、参考にするのがPythonで書かれていたので、こちらでトライです。


一旦以上です。

Lambda関数がどうなったかは次回お送りします。

よろしくお願いいたします。

[AWS]Athenaについて(その2 動作編)

2018.08.06

大変お世話になっております。pinocoです。


前回、抽象度の高いところでAthenaやAthenaの周辺環境について整理しました。


今回はとりあえず触ってみて、


どんな感じで設計すればいいかな、


ということを頑張ってまとめてみようと思います。


 


1.前回なんとなくわかったこと


・Athena自体の料金は「クエリごとにスキャンされたデータ量」で算出される(S3は別途通常の使用料金)


・Athenaのデータ処理はオンメモリで行われる


この2点からAthenaでクエリ発行時に読み込むデータ量を減らすアプローチが、


なんとなく性能的にも、お財布的にも優しそうである


ということがわかった気がしました。


では、とりあえずAthenaを動かしてみて


具体的にアプローチとして取れる手を整備していきたいと思います。


 


2.とりあえずAthenaの動作環境を整える


Athenaを実際に動かそうと思って一番最初に考えたのが


データをどう準備するかな、というものでした。


「public  datasets」で、ざっと検索してみると


kaggleAWS、なんならgithubにawesome-public-datasets


なんて言うOpenDataのまとめ情報もあり、


なんだかすごく助かるなーと言う気分になったのですが


後ろに控えているパーティション分割のことを考えると


割とどんなカラム持ってれば適合しそうか、2秒くらい悩みます。


なぜ2秒で済んでいるかと言うと、実は「どうしたらいいのかなー」から


ビタイチ思考が進まないため「どうしたらいいのかなー」→ timeout(2sec)と言う


絶望的な構造です。思考とは一体どう言う状態を指すのか再度捉え直したい、そう思いました。


でその末にTop Baby Names in the USを選択します


データ量としては約230KBなので、フルスキャンで10MB(10MB以下は切り上げ)


バッチ組んで延々フルスキャンするクエリを結構投げ続けるみたいなことをしなければ、


Athenaのクエリで私の財布が粉微塵に爆発四散阿鼻叫喚な自体は避けられるはずです(多分)


<余談>BigQueryだとドキドキを緩和するdry run(クエリ実行時の走査バイト数の確認)があった気がしましたが


    Athenaだと何が該当しそうかすぐにはわかりませんでした。


 


じゃあ実際にS3に放り込んで、テーブル作ってクエリを投げてやったりましょう。


とりあえず事前に適当なバケットに先ほど取得したデータを放り込んでおきます。


AthenaのコンソールからCreateDataBaseが見つからないので


とりあえずCreate tableを選択すると、「[超訳]Glue使おうや、楽やで」と言う


表示が「手動でやるんや」と並んで出てきます。


 



が、Glueの利点を噛みしめるためにも、一度手動でいばらの道を通ってみます。


人生は選択の連続なのですね。


↓Databaseも新しく作って、先ほどのデータが入っているbucketを指定してテーブルを作成します。



 


↓データはCSVなのでCSVを選択



↓カラムは1個づつ定義できそうな画面だったのですが、Bulk addみたいなのがあったので、それで指定しました



↓最後にパーティション作成するかって感じの画面になりましたが、データがパーティションに適合した形式ではないためそのまま行きます



↓予想通りヘッダー行が入ってて、深くため息をつきます。


気をとり直して、ざっと作り直します。



 


作り直した。※ヘッダ消して再度データファイルをuploadしてテーブル作り直し



ようやく準備が整ったので、クエリを実際に投げてみようと思います。


私の生まれた年にどんな名前をつけるのが流行ったのかみてみます。


select name ,gender, sum(occurences) as summary 
from "test"."test"
where year = 1983
group by name, gender
order by summary desc

 


やー!


女の子はジェニファー、男の子はマイケルが入ってきました!


ここで3位にクリストファーがきているのもなかなか興味深いです。


画面中程にDataScannedとスキャンされたデータサイズが書いてありますが、


225.32KBになっているので、S3上に配置したcsvを全て読み込んでいるのがわかります。



 


では州別で同じようにみてみましょう。


select name ,gender, state, sum(occurences) as summary 
from "test"."test"
where year = 1983
group by name, gender, state
order by summary desc

 


やー!


カリフォルニアとニューヨークでマイケル・ジェニファークラスタが強固な一方で、


テキサスでクリストファー勢が勃興していますね。


クリストファーといえばクリストファーウォーケンくらいしか思いつかないのですが、


おそるべしですね。


 



 


ああ。全然やりたいところまでたどり着けなかったんですが、


今日は、ここで時間切れなので、次回にパーティションのあたりを触って


設計に少しでも入れるといいなと思います。


つづく


 


 

[AWS]AWS Configでルール違反検知 その1

2018.08.01

こんにちは。

middleと申します。


私が日々の業務でぶちあたった壁などについて書いていきたいと思います。

どうぞよろしくお願いいたします。


 


★今回のお題


セキュリティグループの開けてはいけないポートを開けてしまった時、検知したい


その1 背景〜使用するサービス選択 ←本日はこちら

その2 AWS Configとは

その3 カスタムルール作成①

その4 カスタムルール作成②

その5 AWS Config設定〜まとめ


 


★背景


お客様からこんなご要望がありました。



AWSサービスを利用して、どの程度のレベルで監査が可能なのか知りたい。

自分たちで定義したルールに違反する操作があった時、通知させることは可能なのか。

例えば、セキュリティグループのルールを編集している時、開けてはいけないポートをオペミスで開けてしまった場合、検知をしたい。



※背景の背景:現在別クラウドからAWSへの移行案件に参加してます。


 


★調査開始


監査といえば、ぱっと思いついたのがTrusted Advisorです。

ただTrusted AdvisorはAmazonの推奨に基づいて緑・黄・赤でお知らせ、みたいなイメージだったので、なんとなく出来なさそう、とは感じてました。



▲こんなんですね。


実現可能かどうか緊張が走ります。


 


★サポートに問い合わせ


いきなり禁じ手(?)ですが、サポートに問い合わせました。

※研究ではなく業務なので、躊躇なく聞いていくスタイルです。



AWS環境を構築および操作している際、誤ってルール(後述)に反した設定をしてしまった場合に、

検知および通知を行うようなサービスがあれば教えてほしいです。


ルールとしては以下です。

 ・SGが特定のルールに従っているか。

(禁止しているはずの通信を許可してしまっていないか)


どこまで自動でチェックできるか、自動化できるものを知りたいです。


イメージとしては、例えばですが、

ルールをあらかじめ定義しておき、その定義したルールに違反したものがあればメール通知が来る、

のようなサービス(機能)です。



 


★サポートの回答


お返事をいただきました。



AWS リソースの設定があるべき状態であるかどうかのチェックを行い、不適切な設定である場合は通知を行うことを実現するためのサービスは、現状 AWS Config というものがございます。


定められたルールに基づきリソースの設定値をチェックする機能を有しており、

CloudWatch Events と連携を行うことで、ポリシーに反したリソースが検出された際に通知を行うことも可能でございます。


AWS Config では、AWS が提供するマネージドルールと、お客様が Lambda Function で独自に実装可能なカスタムルールの2種類をご利用いただけます。


ただし、残念ながら現状下記を完全に満たすマネージドルールはございません。このため、こちらのチェックについてはカスタムルールを別途作成いただく必要がございます。


> ・SGが特定のルールに従っているか。(禁止しているはずの通信を許可してしまっていないか)



※一部抜粋&改変してます。


実現出来そう、ということでまずは一安心です。

そしてまさにこれぞ、というAWS Configなるサービスがありました。

ただし「カスタムルールを別途作成いただく」のあたりが多少気になるところです。

一筋縄ではいかない気配……。

ひとまず、こちらのAWS Configを利用していくという方向性までは見えました。

続きは次回お送りいたします。

以上です。

よろしくお願いいたします。

[AWS]LambdaでEC2の起動・停止を制御する

2018.07.24

Lambdaについて弊社ブログを検索したところ、


引っかかってきませんでした。


ちょうどEC2の起動制御をしたいなと思っていたので、


今日はLambdaを利用したEC2の起動制御について書きたいと思います。


・LambdaによるEC2の起動制御について


上記を実現させるために必要となる要素は以下です。


1.Lambda(EC2起動制御用APIをキックする)


2.IAM Role(1.のAPIをキックできる権限をLambdaにつけてあげる)


3.CloudWatch Events(1.のAPIをどのタイミングでキックするか、のトリガーとして仕様)


なので


[CloudWatch Events契機で]


[Lambdaを起動し]


[Lambdaは自身にアタッチされているIAM RoleによってEC2起動制御用APIを叩く]


となります。


じゃあ実際にやって見ましょう。


・やってみる


クラスメソッドさんのナイスなブログに当然のように上記処理が存在したため


「こんなに頼りっぱなしでいいんか?」と小さい声で言いながら


当然のように参考にさせていただきました。ありがとうございます。


 


AWS management ConsoleのLambdaから関数の作成に進みます。


名前は分かり易いものをつけておくといいと思います。


ランタイムは利用したいものを選択します。


でロールのところで「カスタムロールの作成」を選びます。


 


 



 


すると、IAM Roleを設定する画面に遷移するので、以下のように設定してあげました。



Policyに関して今回欲しい権限はec2の起動・停止なので、


ec2:"startInstances"とec2:"stopInstances"を付与します。


ハイライトしているlogs(CloudWatchLogs)の権限は、


Lambdaの実行結果を書き込むために必要となる権限セットです。


{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "*"
}
]
}

 


これでRoleの設定まではできたので、次に進みます。


それにしても、分かり易いUIですね。



 


今回はスケジュールベースでの実行を考えているので、CloudWatchEventsをトリガーにします。


GUIからCloudWatchEventsを選ぶと、処理の流れがざっくり完成した図が出てきて、


まるで自分が何かを成し遂げた気分になりますが、幻想です。


ここからまずは画面下のトリガーの設定(CloudWathcEvents)をやっていきます。


 



 


でこのような感じで設定しました。


 



 


スケジュール式のところはcron形式を利用しました。


記載方法は以下に従っています。


Rate または Cron を使用したスケジュール


ちなみに、毎日09:00(JST)に起動させたいと思ったので


cron(0 0 * * * *) 


こういう風に書くと自分の中では思ったのですが、


上記リンクの例だと以下のようになっています。


cron(0 0 * * ? *) 


?は「値を指定せず、指定した別の値とともに使用されます。


  たとえば、特定の日付を指定したが、その日が何曜日であってもかまわない場合です。」


と説明されています。


であれば「*」でいいじゃないかと思うのです。


ものすごく気になったのでよく読んでみると、ドキュメントの最後に


日または週日の値は疑問符である必要があります (?)。


と記載がありました。が、週日の値あたりがより謎を深めてきます。


ちょっと、よくわからないので言語をEnglishにしてみます


One of the day-of-month or day-of-week values must be a question mark (?).


なるほど、少なくともday-of-monthかday-of-weekの


どちらかは「?」を使ってないといかんと。


おそらくいずれも値を設定しちゃうと動かなくなるとか多いから


わざとこういう制限を入れたのだと勝手に推測しました。


で、stopも同じよう18:00に動くようにして、イベントを作って、そこで気づきました。


 


あれ、これってどうやってstartとstopを打ち分けるんだっけ?



Lambda側にわたすパラメータの設定をするところ見落としたのかなー?


と思って見て見ますが、特になさそうでした。


Lambdaに統合された方じゃできなくて、CloudWatchの画面でしか設定できない系かもしれないですね、と


CloudWatch側で再度Eventを作成して紐付けます。


※Lambda側の画面での設定は早々に諦めたのですが、見落としや、良い方法あればお教えください。


ということで、CloudWatch->Eventsからパラメータをふくめて再度設定します。


 



これからの予定が10回分表示されます。


inputはJSON形式で渡しています。


{"Action": "start", "Region": "ap-northeast-1", "Instances": ["************"]}  


 



 


同じように停止の方も作ってあげて同じLambda関数に紐付けます。


では最後にLambdaで実行する処理を記載します。


このハンドラの引数:eventにCloudWatchEventsにて設定したinput(json)が渡されます。


import boto3

def lambda_handler(event, context):
region = event['Region']
instances = event['Instances']
ec2 = boto3.client('ec2', region_name=region)
if event['Action'] == 'start':
ec2.start_instances(InstanceIds=instances)
print ('started your instances: ' + ", ".join(instances))
elif event['Action'] == 'stop':
ec2.stop_instances(InstanceIds=instances)
print ('stopped your instances: ' + ", ".join(instances))

で、CloudWatchEventのスケジュール時間をずらして、起動テストを実施して見ます。


 


 



ログ上はうまく行ってそうです。


これだけマスクするともはや何かわかりませんが、インスタンスもきちんと起動してくれていました。



これがどなたかのお役に立つと幸いです。

1 / 2312345...1020...最後 »