はじめてのAWS NW（その１）

投稿日: 2022/03/28

はじめに

こんにちは、園田です。
AWS利用において、もっとも基本的ではあるものの、実はよく分かっていない、どのような設計が正しいのか分かっていない。という意見をよく聞くのがNWではないでしょうか。

NWについても様々な機能がアップデートされていますし、また元々サーバエンジニアやプログラマーが取っ付き難い分野でもありますので、本日は改めてNWについてお勉強をしたいと思います。

なお、説明の都合上、概念のみの説明で具体的な設定画面等が無い場合あります（ページが足りないので）が、そちらはご了承ください。

AWSにおけるNWサービス

AWSにおけるNWサービスについては以下の3つのみとなります。（マネジメントコンソール上の枠組みでの記載）

• VPC
• DirectConnect
• Route53

Route53は純粋なNWというよりはDNSのサービスとなりますので、実質は2つ。DirectConnectを利用しないユーザについては全てVPCのサービスから設定が可能となります。大変便利な反面、１つのサービスで複雑なNW機能を設定できることから分かりにくさにつながっているような気がします。

では、１つずつ見ていきましょう。

VPCを設定する

まずはVPCの設定からになります。
機能としては、マネジメントコンソールの「VIRTUAL PRIVATE CLOUD」の項目の「VPC」、「サブネット」、「ルートテーブル」、「インターネットゲートウェイ」があれば基本的な設定はおおよそ設定可能です。

1．VPC

まずは、VPCを作成します。
VPCはAWS上に閉じたNW空間を作ることが出来る機能となります。
標準では1アカウントあたり5VPCを作ることが可能です。複数のVPCを作っても問題ありませんが、AWSにおいてはオンプレミスの環境と違いNW配線を誤ってしまいブロードキャストストームの影響でNWが全断してしまうなどの危険性はありませんので、検証、ステージング、本番という形で複数のVPCを作る理由は基本ありません。
通信制御はセキュリティグループで、サーバ単位で実施できるため管理の観点からVPCは1つとすることを推奨します。

なお、AWS利用時、標準でデフォルトVPCというものが存在します。
このデフォルトVPCはNWレンジも固定、インターネット接続等も標準で接続できる形になっていますので削除しておくことを推奨します。（削除しても後で元に戻せます）

VPCのNWレンジについて

VPC作成時、IPのアドレスレンジを指定することが可能です。アドレスはIPv4の場合、「/28」～「/16」となります。任意のアドレスを設定することが可能ですが、基本はプライベートアドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）から払い出す形になるかと思います。会社としてグローバルアドレスを持っている（もしくは利用している）場合、グローバルアドレスをVPCに設定しても問題ありません。ただし、その場合、インターネットから直接割り当てたグローバルIP対してアクセスは出来ません

そのため、グローバルIPを利用する場合はあくまで、オンプレミスがグローバルIPを使用しているため、オンプレミス環境と通信を行うために利用という形になります。

先ほどVPCのIPアドレスについては、「/28」～「/16」と記載しましたが、例えば「/24」のIPアドレスを設定しアドレスが枯渇した場合、同じ第1オクテットのIPアドレスレンジであれば4つまでCIDERが追加可能です（初回の作成とあわせて最大5 CIDER）。
10.X.X.XのVPCに対し、192.168.0.0/24などのCIDERは追加できませんので追加を前提とした設計をする場合は、IPアドレスの空きについて確認の上、構築を行いましょう。

こんな感じで追加可能。

2．サブネット

続いてはサブネットを作成します。初回、および追加で割り当てたVPCのアドレスレンジからサブネットを作成することが可能です。
実際のインスタンス（EC2、RDSなど）は作成したサブネットに配置する形になります。
サブネットのアドレスレンジはVPCと同様、「/28」～「/16」となります。このサブネット作成時に、アベイラビリティーゾーンを選択することが可能です。

耐障害性を鑑み、2つ以上のAZを利用した設計（可能であれば3つ）とするのが望ましいです。

今回は話を分かり易くするため、10.0.0.0/16のVPCに対し、10.0.0.0/24（1aのAZ）、10.0.1.0/24（1cのAZ）、10.0.2.0/24（1aのAZ）、10.0.3.0/24（1cのAZ）の4つのサブネットを作成したという事にします。

こんな感じで作成しました。

3．ルートテーブル

最後にルートテーブルの設定を実施します.
AWSでは、publicセグメント、privateセグメントというものは存在しません。純粋にルートテーブルの設定として、インターネットに接続できるルートテーブル設定（0.0.0.0/0をigwに設定）したものをpublicセグメントと呼んでおり、インターネットへの直接ルーティングが無いものをprivateセグメントと呼んでいます。

今回は10.0.0.0/24、10.0.1.0/24をpublicセグメント、10.0.2.0/24、10.0.3.0/24をprivateセグメントという事で作成してみます。

ルートテーブルはpublicセグメント用、privateセグメントA、privateセグメントBの3つを作成し、サブネットの割り当てを行います。

ルートテーブル作成後、「サブネット関連付け」タブの「サブネットの関連付けを編集」をクリックし、明示的にルートテーブルに対し、サブネットの割り当てを行います。 サブネットの関連付けを実施しない場合、デフォルトのルートテーブルに割り当てが実施されます。後々の運用を考え、通信が出来る・出来ないではなく必ず正しく設定を実施しましょう。

続けてルーティングの設定になります。
ルートテーブルの「ルート」から「ルートを編集」をクリックします。

ルートの編集画面にて、ルーティングの設定が可能です。ルートテーブル作成時にデフォルトのルーティング設定として、VPC内のすべての通信が可能となるルーティングが設定されています。この設定については削除することが出来ません。そのため、各インスタンスについては必ずセキュリティグループにて必要な通信のみ開放する形にしてセキュリティを確保しましょう。

publicセグメントの場合、送信先を0.0.0.0/0、ターゲットをインターネットゲートウェイとすることで、インターネットへの接続が可能となります。（事前にインターネットゲートウェイを作成し、VPCにアタッチしておく必要があります。インターネットゲートウェイ作成後、「アクション」→「VPCにアタッチ」で事前準備が完了となります。）

privateセグメントの場合、各サーバからインターネットに接続する要件があるかと思います。
AWSからインターネットに接続したいという場合、送信先を0.0.0.0/0、ターゲットをNATゲートウェイとすることでインターネットに接続することが可能です。
後で触れますが、オンプレミスのproxy等を通ってインターネットに出たいという場合は、仮想プライベートゲートウェイを選択します。
NATゲートウェイについてはAWSがマネージドサービスとして提供しているNAT（NAPT）サーバになります。NATゲートウェイ作成時、どのサブネットに作成するかを選択することが出来ます。
冗長化確保の為、10.0.0.0/24（1aのAZ）、10.0.1.0/24（1cのAZ）の両方にNATゲートウェイを作成します。

纏めると以下のような形で設定を実施しました。

• pullic用ルートテーブル：
  10.0.0.0/24（1aのAZ）、10.0.1.0/24（1cのAZ）を関連づけ
  0.0.0.0/0　→　インターネットゲートウェイ

• private-A用ルートテーブル：
  10.0.2.0/24（1aのAZ）を関連づけ
  0.0.0.0/0　→　10.0.0.0/24（1aのAZ）に作成したNATゲートウェイ

• private-B用ルートテーブル：
  10.0.3.0/24（1cのAZ）を関連づけ
  0.0.0.0/0　→　10.0.1.0/24（1cのAZ）に作成したNATゲートウェイ

なお、今回はとりあえず3つのルートテーブルとしましたがオンプレミスと接続するにあたり、本番用のサブネットと開発用のサブネットは通信先が異なる可能性がある、などの場合は本番用とテスト用にルートテーブルを分けておくことを推奨します。（その場合はprivate用のルートテーブルが合計4つになる）

「1．VPC」、「2．サブネット」、「3．ルートテーブル」の設定を実施することで、とりあえずもっとも基本的なNW構成が完了しました。とはいえ、これだけではオンプレミスからの接続も出来ませんし、大規模利用（複数のAWSアカウント利用）も考慮されていません。

少し長くなってきたので、一旦はここまでという事で次回に続きます。次回はオンプレミスとの接続という事で、DirectConnect、およびVPNについて記載したいと思います。 では次回でお会いましょう。

• VPCとサブネットのアドレスレンジについて
  VPCのアドレスをどのようにすればよいかについて、よく問い合わせをいただきます。という事でVPCに割り当てる最適なIPアドレスについて考えていきたいと思います。

  結論としては環境に依るといいたいのですが、それではコラムにならないので多少理由付けを含め自身の考えを記載していきたいと思います。

  まずはサブネットのIPアドレスをいくつにするかという事になるかと思います。AWSのドキュメントにELBのサブネットは/27以上にしなさいと記載があるため、/27を最低のサブネットレンジとします。（ELBを/27、EC2を/28でも良いのですが管理が面倒（運用負荷が掛かる）であるため、サブネットのレンジは統一します）
  https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/application-load-balancers.html

  「/27」の場合、利用できるIPは一般的には30IPとなりますが、AWSの場合はサブネット+1はゲートウェイ、+2はDNS、+3は予約となっているため、27IPという形になります。
  ぶっちゃけ、27IPあれば基本大体のシステムはOKでしょう。

  という事で仮に192.168.0.0のNWを利用するのであれば、
  192.168.0.0/27 public（AZ、1-a）
  192.168.32.0/27 public（AZ、1-c）
  192.168.64.0/27 private（AZ、1-a）
  192.168.96.0/27 private（AZ、1-c）
  という形になるため、192.168.0.0/25のVPCで問題なしという形になります。

  ただNWの管理としては一般的に/24で管理しているのが一般的となるため/25だと管理が難しいという課題が出る場合があります。 この辺も鑑みると「/26のサブネットを4つ作って足りなくなったらおかわりをする」、もしくは「/27を4つ作っておいて、足りなくなったら後4つ足せるようにしておく」というのが一般的なあ。と感じています。

  正直クラウドではブロードキャストストームの影響でNWが全断する、またはNW単位でFW制御をするという事が無いため、細かくサブネット設定する意味が基本ありません。
  とはいえ、オンプレミスや他のAWSアカウント、または他のクラウドと連携を考慮した際、考え無しに大きなNWを作成するというのは考え物です。
  後で要件が変わって接続要件が出ることも鑑み、会社として管理しているIPアドレスレンジから払い出しを怒ってもらうのがベストだと考えます。

  色々と考慮すると一番基本的な「/24」になってしまうというのがなんとも微妙な所ですね。

おわりに

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。