sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Auto Scaling で EC2 インスタンスをメンテナンスする時の注意点 [cloudpack OSAKA blog]

明けましておめでとうございます!ナスです。
今年も適度に頑張って記事を書いていきます。

今日は Auto Scaling でヒヤリとしたことを書きます。

 

事の発端

とある作業で、Auto Scaling グループ内の EC2 インスタンスを再起動しないといけなくなりました。Auto Scaling とは関係なければ普通に再起動して終わりですが、Auto Scaling グループに入っている EC2 インスタンスを再起動すると、タイミングによっては ELB のヘルスチェックに引っかかって Terminate されてしまう可能性があります。

 

私がやったこと

手順は前もって調べて作業に着手したので問題はない、はずでした…
やった作業は以下の通り。

Auto Scaling グループのコンソールのインスタンスタブから、対象の EC2 インスタンスを「スタンバイに設定」にする。(もう存在しない EC2 インスタンス ID なのでモザイク無しで)
f:id:nasrinjp1:20170104231225p:plain:w500

スタンバイ状態になったことを確認して、EC2 インスタンスを再起動し、再び「実行中に設定」にする。
f:id:nasrinjp1:20170104231233p:plain:w500

たったこれだけです。

 

何が起こったのか?

作業完了してしばらく Auto Scaling グループの EC2 インスタンスの1つが Terminate されました。もうちょっとしたパニック状態です。こう言うのをテンパるというのでしょうか。

 

原因は何だったのか?

よくよく Auto Scaling グループの設定を見ると、希望インスタンス数が1つ減ったままになっていました。
スタンバイに設定すると、希望インスタンス数が1つ減らされます。下図はもともとの設定です。(もう存在しないサブネット ID なのでモザイク無しで)
f:id:nasrinjp1:20170104231213p:plain:w500

スタンバイにするとこうなります。
f:id:nasrinjp1:20170104231230p:plain:w500

また実行中に戻すと3に戻るんですが、作業した AWS アカウントでは2のままになっていました。
そうすると、スタンバイから実行中になってインスタンスは3台になったのに、希望インスタンス数が2のままなので、Auto Scaling が1台多いなって思って余分な EC2 インスタンスを削除した、というわけです。

 

どうすればいいのか?

私の検証用 AWS アカウントでは同じ事象は発生しないので、何か気づいてない条件があるのか、AWS アカウント固有の問題なのか、Auto Scaling のバグなのかはわかりません。が、とりあえず暫定策として、停止したプロセスに Terminate を追加することにしました。
f:id:nasrinjp1:20170104231237p:plain:w500

これで希望インスタンス数が戻らなくても、突然 Terminate されるなんてことは起こりません。

 

AWS のサービスがいろいろやってくれるとはいえ、過信しちゃダメなんだなと思いました。というか、同じ作業して 2つの AWS アカウントで結果が違うってなかなかキツイ…

 

2017.01.12 追記
続編書きました。
nasrinjp1.hatenablog.com

AWS のセキュリティレベルがまた上がった! [cloudpack OSAKA blog]

ナスです。

re:Invent が終わって1週間経ちましたが、皆さん新サービスで使ってみたいものはあったでしょうか? たくさんのサービスがリリースされたので、正直全部追いきれないというのが私の感想です。
各社、各個人のブログ等で新サービスの紹介がされていますが、私からはすごく地味だけど重要な新サービスを今さら紹介してみます。

これで、AWS を使わない理由が減り、AWS を使うべき理由も増えました!

 

AWS Shield!

aws.amazon.com

AWS Shield Standard は追加費用なしで、すべてのAWS顧客が利用できます。 SYN/ACK フラッド、リフレクション攻撃、HTTPスローリードなど、今日最も一般的な攻撃の96%からお客様を守ります。 この保護は、Elastic Load Balancer、CloudFrontディストリビューション、Route 53リソースに自動的かつ透過的に適用されます。

全部とは言いませんが、既知の攻撃からは守ってくれそうな文言です(残りの4%ってなんだろう?)。しかもタダで、ELB、CloudFront、Route53 に自動で適用してくれます。これ、他のクラウドサービスやデータセンターだとどうでしょうか? ほとんどが「それはお客様の責任範疇です。」って回答になると思います。基本的にすべての攻撃を完全に防ぐことは不可能なので、96%が正しいとすると、Standard でも十分に効果がありますね。あとは、攻撃の被害にあったことを想定して運用を考えるだけです。

 

クラウドはセキュリティが心配ってまだ言いますか?

AWS に限らず、各クラウドサービス提供事業社はセキュリティに関しては非常に気を使っています。顧客の情報を預かる上では当然のことです。例えば、AWS では「FISC 安全対策基準」についてどのように遵守しているかを公開しています。

aws.amazon.com

FISC 安全対策基準の対応状況リストで、かなりの項目が基準を満たしていることがわかります。例えば、この「FISC 安全対策基準」、皆さんのシステムが置いてあるデータセンター等では満たしてますか? もし満たしてないのであれば、AWS の利用について心配する前に今の状況を心配しないといけません。

 

AWS は、使った分だけ使用料を払うだけでよく、しかもその使用期間中は上記のような高度なセキュリティを提供してくれて、そのセキュリティは AWS 使用料に含まれています。同じ仕組みを自社で作ろうとすると時間もお金も足りません。利用者がこれだけ安価にメリットを享受できるサービスはそう多くありません。

AWS を使いたいけどセキュリティガーって言われて困っている人はこういうネタが参考になると思いますので、説得ネタとして頭のどこかに置いといてもらえればと思います。