こんにちは。いそやです。
オンプレミスでの経験はありますが、慣れないAWSに四苦八苦しています。それでもAWSは楽しいですね！
その四苦八苦の中でも、AWSのElastic Load Balancer(ELB)の使用にあたってプライベートサブネットに配置したサーバーへのアクセスができず、とても困ったことがありました。
AWS初心者にはなかなか理解できなかったので、その顛末をブログにしました。
初めてELBを使ってみようという方が対象になります。
今回の検証用環境
インターネットゲートウェイ経由で、VPC内に構築したALB→各プライベートサブネットのwebサーバーにアクセスします。
上記の構成で、おや？と思われた方もいるかと思いますが、その違和感にたどり着くまでが長かったです…。
なお、今回はELBの中でもApplication Load Balancer（以下、ALB）を使用しました。
今回の目的
- HTTP接続でALBを経由して、異なるプライベートサブネットに配置したwebサーバーにアクセスを振り分けたい
困ったこと
上記の検証環境を構築し、webサーバにApcheをインストールし、簡単なwebサイトを準備しました。
ところが、ブラウザからALBにHTTP接続したところ、待てど暮らせどレスポンスがありません。
最終的にはタイムアウトとなり503エラーとなってしまいました。
セキュリティグループやルーティングテーブルの設定を見直しましたが、特に誤りと思われる該当箇所はありませんでした。
思い当たること
ALBの「サブネットの編集」で「インターネット向けロードバランサーを作成中ですが、次のサブネットにはアタッチされたインターネットゲートウェイが存在しません」との警告表示が出ていました。
同様にアクセスできない事象に対してプライベートサブネットにインターネットゲートウェイを設定することで解消しているケースを散見しました。
しかし、インターネットゲートウェイを設定することでパブリックサブネットとなってしまい、今回の目的に合致しないため警告を無視して強行設定しました。
この時はルーティングしたいサブネットを指定するもの、と思い込んでいました。
そもそも理解できていなかったこと
そもそもALBは各AZ毎に設置される
上記の構成図のようにVPC内にALBがあれば良いと思っていました。しかし、オンプレミス環境に置き換えて考えれば、データセンター内にインターネットの入り口となるインターネットゲートウェイに繋がったALBが存在しないことがそもそもおかしいことですよね。
ですから、先ほどの「サブネットの編集」ではルーティングしたいサブネットではなく、ALBを配置したいAZ内のパブリックサブネットという理解になります。
ルーティングの対象はターゲットグループの役割ですね。
対応策
- プライベートサブネットしか存在しないAZにパブリックサブネットを作成
- ALBに紐付けるサブネットをパブリックサブネットに変更
パブリックサブネットに紐付けたところ、先ほどまで出ていた警告文が表示されていないことがわかります。
対応後の構成図はこちら。
対応結果
無事にALB経由で各webサーバーにアクセスできました！
感想
特定のAZ内にプライベートサブネットしかない本番ではあり得ない検証環境であること、ALBのサブネット選択をミスしたことによる事象ではありましたが、おかげでALBの挙動がよく理解できました。
AWSに触れる方はクラウドネイティブな方も増えてくると思いますが、ブラックボックスになっているデータセンター内ではどうだろうか？という原点に立ち返って検討してみることも遠回りにはならない、と実感した次第です。
…と思っていたら、公式ドキュメントにばっちり解決策が書いてありました。まず公式ドキュメントを読むべきといういい教訓になりました…。それにしてもAWSって楽しいですね！
aws.amazon.com
