business-switchx4500

AWSを一年使ってみて、最初から知っておけば良かったこと

AWSを使い始めて約一年が経過したので、この一年を振り返ってみて、最初から知ってた方が良かったな〜と思ったポイントをピックアップしてみました。

IAMロールはName変えられないし付け替えもできない件

勢いだけで作ったIAMロールを付与して意気揚々と運用開始!数ヶ月後に付け替えできない事に気付いて、ec2ctrlとかいかにもEC2インスタンスをコントロールするためのロールなのに、なぜかS3の全権限付与してたり、もはや名前から予測できない事態になってしまったという話。

まぁ、別にオオゴトでは無いんですけどね。インスタンス作り直せば付け替えできるし、新しいロール作ってインスタンス作り直せばいいだけの話です。やるかやらないか。

やりませんけど!

VPCでVPN接続はリージョン毎に1つしか設定できなかった件

IDC側のグローバルIPが複数用意できない前提ですが、IDCとAWS(VPC)間でのVPN接続は、同一リージョンの別アカウントで接続済みだった場合、接続を確率できませんでした。

ルーター側に問題があるかもしれないとも考えましたが、他の拠点と結びまくっていて安定しているので考えにくい状況だったので、別の方法を探すことに。

色々検討した結果、VyattaのAMIを元にソフトウェアVPNで接続することに成功。パフォーマンスはかなり落ちるものの、接続しなくてはいけないという一番の目的だけは達成できました。

もし、これから接続しようとしていて、社内の他部署で接続している可能性がある場合は先に確認しておくことをオススメします。

RDSのMySQLでTimezoneをUTCからJSTに変えるのが力業すぎる件

結論、変更できるんですが、init_connectにTimezone変えるコードを記載するという無理矢理感が否めない実装で着地するという話。

RDS(MySQL)でJSTを使う たった1つの冴えたやり方

これが一番無難な印象。手元の環境はストアドプロシージャにしちゃって、まさにストアド入れる前にパラメータグループ適用しちゃってハマったことあります。

ELBに固定IPを割り当てることはできない件

そうなんです、EIP取って割り当てようと思ってもどうやればいいか分からず、調べると出来ないことが判明する・・・って流れ、AWSあるあるにエントリーできるくらい多いと思います。

使い慣れると当たり前になっちゃうんですけど、初めて知ったときは衝撃的でした。

ELBが一度OutOfServiceになったEC2を再認識しない件

elb-outofservice

EC2を停止して再開した場合、自動的にInServiceになりません。公式マニュアルによると、「認識するまでに時間がかかる」という説明にとどまっていますが、数分放っておいてもInServiceにならなかったので大人しく登録しなおす運用に変えました。

EC2-VPC インスタンスを停止して起動した場合、停止したインスタンスが起動されたことをロードバランサーが認識するまで時間がかかることがあります。その間、ロードバランサーは再起動したインスタンスに接続されていません。

引用元:Amazon EC2 インスタンスの登録解除と登録

ちなみに、一度OutOfServiceになると、除外→登録を手動で行うのが面倒なので、SDKでderegister〜registerを自動化するといい感じに運用できます。

まとめ

多分探せばもっと出てくるんですが、印象的だったのはこの五つでしょうか。

個人的に一番苦労したのはVPN接続でした。これは丸3日くらいハマったので、似たようなことでハマってる方は早々に見切りをつけた方がいいかもしれません。

二番目に困ったのはELBに固定IP割り当てられないこと。VPNで接続してローカルIP割り当てて負荷分散するって選択肢が無くなったのは少し困りました。

オンプレからAWSに切り替えようとする場合、事前調査がかなり大変だと思います。特に、既存システムの移行をする場合、結果的にハイブリッド構成(IDC+AWS両立)で落ち着くケースが多いので、IDC〜AWS(VPC)間のVPN接続は避けられないと考えた方がいいかもしれません。