nologyance.net

日々のアウトプット

ELBを作成する際の注意点

そこまで冗長化は必要ないけどそれなりにセキュアにしたい場合のVPC構成

このスライドの右(あるいは左)半分のみ構築してEC2を運用されている方もいるのではないでしょうか。 私もその一人です。

この構成の何が良いかというと、 見出しのとおり、そこそこセキュアで安いという点。

すべてをpublic subnetに曝け出しているよりはかなり安全になります。

ELBを追加

この環境でAutoscalingを実施するためにELBを立てるとします。 すると困るのがsubnetの扱い。

ALBを作成する際には配置するsubnetを2つ指定しなければなりません。 今存在するsubnetは2つしかないのでそれぞれ指定します。

すると「次のサブネットにはインターネットゲートウェイが存在しません。」との表示が。 そりゃprivate subnetはNATゲートウェイ経由にしてるからな! と自信満々に作成してしまったあなた(私)、こんな現象に出くわしていませんか?

たまにインスタンスに繋がらない(極端にレイテンシが増加する)

低負荷状態であるにもかかわらず、なぜかインスタンスに繋がらないことがある。 ヘルスチェックを確認しても特に異常なし。 繋がらない、ではなく繋がらないことがある。というのがやっかいなところ。 私もかなり頭を捻りました。

するとこんな記事を発見

https://stackoverflow.com/questions/35523421/aws-elastic-load-balancing-seeing-extremely-long-initial-connection-time

どうやらインターネット向けのELBにprivate subnetを紐づけるのは間違いらしい。

ちゃんと公式にも回避策が書いてありました。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/public-load-balancer-private-ec2/ 空のpublic subnetを作って紐づければよいみたいですね。

ELBが配置される場所

作成時にsubnetを指定するので、てっきりターゲットが存在するsubnetに配置しなければいけないものだと思い込んでいましたが、どうやら違うみたいです。 バランシングの候補になるのはおそらくELBが配置されているAZ全体。

むしろインターネット向けのELBをprivate sunbetに配置すると外からは見えない様子・・・ おそらくですが、繋がったり繋がらなかったりしたのはpublic subnet側のAZを経由してprivate側にアクセスが行われていたためと推測しています。

ちゃんと警告は読みましょう

ちゃんと作成時の警告を素直に受け取っていればこんなことにはならなかったのにね。