ELBをVPC内に設置する際のサブネット設計の注意点

  • 50
    いいね
  • 2
    コメント
この記事は最終更新日から1年以上が経過しています。

AWSアドベントカレンダー 18日目の記事です。17日目はinouetさんのDynamoDB ベストプラクティスでした。このアドカレ、途切れず続いてますね、参加できて嬉しいです :tada:

今回は、ELBをVPCのサブネット内に設置するときのサブネット設計について、注意点をまとめます。

サブネットのCIDRのビットマスクに/27以上をつけること

ELBを設置するサブネットでは、スケーラビリティを確保する為にビットマスクが /27 以上必要です。

Configure Amazon VPC for Elastic Load Balancing

To ensure that your load balancer can scale properly, make sure that the subnet in which you plan to place your load balancer has CIDR block of at least a /27 bitmask (e.g., 10.0.0.0/27) and also has at least 8 free IP addresses. When you create your load balancer and place it in a subnet, this defines the subnet that traffic must enter to forward the request to registered instances.

8つIPのプールが必要

上記引用の中に書いていますが、ELBを設置するサブネットには、サブネット全体で 8個 以上のIPアドレス*1の余りが必要です。このサブネット内にELB以外にもEC2インスタンスを配置することができますが、無計画にEC2を稼働させまくると、IPが不足してELBのスケールアウトができなくなってしまいます。

その際、サブネットごとに 5個 のIPがAWSにより予約されてしまうので、通常のネットワーク設計の方法論でサブネットのIP計算をすると、困った事態になりかねません。

例 /27でサブネットを切ってみる

通常のネットワーク設計の場合、サブネットで利用可能なIPアドレスは、

32個のIPアドレス - (ネットワークアドレス + ブロードキャストアドレス) = 30個の利用可能IPアドレス 

となり、2個 のIPアドレスが利用不可能になります。

しかしVPCのドキュメントを読むと

Your VPC and Subnets

Important
AWS reserves both the first four IP addresses and the last IP address in each subnet CIDR block. They're not available for you to use.

と書いており、先頭に 4つ、末尾に 1つ、合計 5つ のIPアドレスが利用不可能になります。

実際の内訳はわかりませんが、末尾の1つは普通にブロードキャストアドレス、先頭の1つはネットワークアドレスだとして、先頭の残り3つが利用できない点が、通常のネットワーク設計と異なりますので、特に小規模なサブネットをギリギリのサイズで設計しようとしている時など、注意が必要です。

*1:AWSドキュメントの別のページでは、20個のIPアドレスが必要となっていて(ただし日本語翻訳のみ。原文には記載なし)、正直よくわからない。
別のページ:

http://docs.aws.amazon.com/ja_jp/ElasticLoadBalancing/latest/DeveloperGuide/UserScenariosForVPC.html

アクセス割り当て先のEC2インスタンスが存在するAZごとに、サブネットが必要

ELBからリクエストを割り当てるEC2インスタンスが存在するAZごとに、ELBを設置するサブネットが必要です。

例えばTokyoリージョンにて ap-northeast-1a と ap-northeast-1c にEC2インスタンスを作成、それぞれにアクセスを振り分けたい場合、両AZにそれぞれサブネットを作成しなければ、アクセスの振り分けができません。(追記: Cross Zone Routing をOFFにしている場合。

エフェメラルポートをNetworkACLで開けておく

以前の記事で書きましたが、ELBからEC2へアクセスする際のリターンポートは通常のLinuxなどとは異なります。

Network ACLs

The client that initiates the request chooses the ephemeral port range. The range varies depending on the client's operating system.
...
Requests originating from Elastic Load Balancing use ports 1024-65535.

このELB用のエフェメラルポート、1024-65535

  • ELB用サブネットのInbound
  • EC2用サブネットのOutbound

にて解放する必要があります。解放相手のIPレンジをそれぞれ

  • ELB用サブネットでの解放 -> EC2用サブネットのCIDRからのパケット
  • EC2用サブネットでの解放 -> ELB用サブネットのCIDRへのパケット

としておくのがセキュアです。

Outro

結構はまりどころの多いELBのネットワーク設計ですが、サービスの受け皿となるノードですので、しっかりと設定したいところです。

あと、AWSに対しこれまで、日本語化されたドキュメントはしっかり原文に追随しているという感想を持っていたんですが、そうでも無いなと思いました。もしくはここ数年で、日本市場のプライオリティが下がり、中国(とか南米とか?)市場重視になっているということなんでしょうか。

まあ英語ドキュメントが翻訳されなくても、特に困らないから良いんですが。。フィンランド語とかなら困るけど。

とりあえず、日本語ドキュメントはもうあまり信頼しないほうがよさげです。

次回、19日目はdigitalbotさんのClojureとKinesisの相性が良さそうという話です。お楽しみに!モイモイ!

追記

VPCのサブネット内で利用できない3つのIPアドレスについて、気になったので調査してみました。

pingを打ってみたところ、pongが返ってきたのは最初の一つだけ(つまりネットワークアドレスの次)だったのですが、Nmap打っても何者かわからず。DHCPサーバーかなと思い、


$ sudo dhcping -s ブロードキャストアドレス

としてみましたが、DHCPサーバーはサブネットの外側(ついでに言うとVPCの外側)にあるみたいで、DHCPサーバーでは無いようです。

SNMPマネージャかな?とも思いましたが、CloudWatchで取得できるメトリクスの種類から見て、ハイパーバイザ側で監視しているだけでSNMPは使っていない気がするし、なんかよーわかりません。管理用なら3つも必要無い気がするし。。

あなたはだれですか?

この投稿は AWS Advent Calendar 201418日目の記事です。