TOP>コラム一覧>はじめてのAWS NW(その3)

はじめてのAWS NW(その3)

はじめに

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

という事で、今回は大規模利用時のNW構成について検討したいと思います。
前回までの記事はこちら

はじめてのAWS NW(その1)
基本的なNWの構成、設定について説明しています。

はじめてのAWS NW(その2)
DirectConnectおよびVPNでのオンプレミスとの接続について説明しています。

AWS NWの大規模利用とは

AWSアカウントについては、アカウントが異なると請求、NW、インスタンスがすべて独立しています。大規模にAWSを利用する場合、権限の観点からAWSのアカウントを分ける必要があります。(ベンダーに作成・削除権限を渡したいという要件があった場合、同一アカウント利用時XXXシステムのみ作成・削除権限を付与するという事は出来ないため、アカウントを分ける必要があります。)

AWS NWの大規模利用とは

そのため、AWSアカウントが増えれば増えるほど、NW(VPC)がアカウント毎に作成する必要があり、各VPC間の接続をどうするのか、オンプレミス環境との接続や、他のクラウドとの接続をどのように担保するかが課題となります。

これを解決するための手段としては以下の2つとなります。

  • 共有VPC(Shared VPC)
  • Transit Gateway

それでは1つずつ見ていきましょう。

■共有VPC(Shared VPC)

任意のアカウントに存在するVPCを複数のアカウントに対し共有する機能になります。 共有VPCの利用イメージとしては以下の通りです。

■共有VPC(Shared VPC)

共有VPCを使う際のメリットは以下の通りです。

  • 1.NW管理アカウントという形でNW管理者が一元的にNWの管理が可能。
    NWのポリシーを共通化できる

  • 2.外部接続がシンプルに構成が可能

  • 3.AWSリソースは各アカウントの物を利用するため、自由にリソースの作成が可能。

  • 4.各アカウントの担当者に深いNWの知識が不要

1については共有されているアカウント側からはNW設定を触ることが出来ないため、必然NW管理アカウントのNW管理者がNWを管理する形になります。例えばproxyを経由してインターネットに接続させたい場合、通常利用時は各担当者がNATゲートウェイを作成してしまう可能性がありますが、共有VPCを利用している場合においては、そのようなことは実施できません。
結果的にNWの統制が取られ、全てのアカウントで同様のNWポリシーを利用する形になります。

2については共有しているVPCにDirectConnectやVPNを接続することで、全てのアカウントがDirectConnectやVPNの接続を利用可能です。
Transit Gatewayを利用することで同様のことが出来ますが、DirectConnectの1G、10G占有回線の制約が発生しないところがメリットとなります。

3については、VPC以外は自身のアカウントのリソースとなるため、自由に設定が可能です。セキュリティグループ等も統制が取れるとよいのですが、共有VPCでセキュリティグループの統制を取ることは出来ません。

4については共有しているVPCにリソースを作成するだけとなりますので、各アカウントの管理者はNWの深い知識が不要となります。NW関連のリクエストがある場合は、NW管理アカウントの管理者に依頼して実施してもらう形になります。

なお、共有VPCの設定は「Resource Access Manager」にて実施します。 やり方としては以下の通りです。

共有を行うサブネットを選択

共有を行うサブネットを選択

共有するアカウントIDを記載することで共有が可能です。途中「関連付けるアクセス許可」の設定が出てきますが、デフォルトで問題ありません。

共有するアカウントIDを記載することで共有が可能です。途中「関連付けるアクセス許可」の設定が出てきますが、デフォルトで問題ありません。

共有VPC(Shared VPC)は大変便利な機能ですが、以下のようなデメリットもあります。

  • 共有するAWSアカウントが全て同一のorganizationに所属している必要があり
  • リセラーからAWSアカウントを購入している場合、リセラーが本機能を利用できないようにしている場合がある(要確認)

そのため、AWSアカウントの購入元が複数ある場合、共有VPCは利用できません。また、事前にNW設計を実施しておく必要があります。

便利な機能ではあるものの制約の重いため、あまり利用されていない機能ではないでしょうか。(大規模な環境は複数のリセラーからAWSアカウントが提供されているのが一般的)

■Transit Gateway

複数のVPCを接続することが出来るサービスになります。
VPCを接続する機能としては、VPC Peeringがありましたが、VPC Peeringを利用する場合、全てのVPCと通信を実施する場合、N(N-1)/2のピアリングが必要となります。(VPCが4つの場合は、6 Peering。5つの場合は、10 Peering)
また、Peeringに伴い、ルートテーブルも設定が必要なり、数が多くなると現実的ではありません。

Transit Gatewayを利用することで全てのVPCと簡単に接続を行うことが可能です。

Transit Gatewayを利用することで全てのVPCと簡単に接続を行うことが可能です。

このTransit Gatewayについては以下のように、DirectConnect、並びにVPN接続を紐付けることが可能です。
ただし、DirectConnect接続を実施する場合、DirectConnectの回線が1Gもしくは10Gの占有である必要があります。そのため、回線コストが上がってしまうことが考えられます。DirectConnectとTransit Gatewayを接続したい場合、必ず回線キャリアに対応しているか、および費用について確認しましょう。(詳細、「はじめてのAWS NW(その3)」を参照)

Transit Gatewayを利用することで全てのVPCと簡単に接続を行うことが可能です。

VPCが10個以下の場合、一旦DirectConnectはTransit Gatewayに接続せず、DirectConnect GatewayとVPCを直接接続するという方法もあります。
この場合、VPCが10個以上に増えた場合、あらかじめどのような設計にしておくか検討しておく必要があります。回線によっては追加で仮想インターフェイスの払い出しを実施することでDirectConenct Gatewayを2つにするという方法もあります。
またDirectConenct Gateway の接続からTransit Gatewayへ接続方式を変更する場合、通信断が発生するため、注意が必要です。

DirectConenct GatewayとTransit Gatewayの混在案

DirectConenct GatewayとTransit Gatewayの混在案

■Transit VPC

TransitGatewayがリリースされてから使われなくなった接続形態になります。
本接続形態についてはAWSの機能を利用するのではなく、VPC内のEC2にBGPルータを作成し(マーケットプレイスからCSR 1000v、SRXなどを利用)、BGPでの経路交換を行うことでVPC間の通信を実施します。
オンプレミスとの接続もDirectConnect、VPNどちらもBGPを利用するため、オンプレミスとの通信も可能です。

構成としては以下のような形を取ります。

構成としては以下のような形を取ります。

ポイントとしては、BGPルータを構築したEC2に対しEIPを付与。BGPルータを設置したVPC含むすべてのVPCからBGPルータに対しBGPを利用したVPN接続を実施。各VPCから接続先のCustomer GatewayのIPアドレスにEC2のEIPを指定することで、Transit VPCを構築することが可能です。

上記構成を取ることで、全てのトラフィックが一度EC2上のルータを経由し、VPC間の通信、またはオンプレミスとの通信を行う形となります。VPCが追加する場合も、追加したVPCからVPN接続(Customer GatewayはEC2上のEIP)を追加することで通信を実施することが可能です。

どちらかと言えば、本機能をマネージドサービスとしてリリースしたものが、Transit Gatewayという事が出来るかもしれません。
本接続を利用することで、DirectConnectの制限なく統一されたポリシーでのNW運用が可能となります。半面、BGPルータの設計、構築、運用が発生するため、高度なスキルを持ったNW担当が必要となります。

AWS NWの大規模利用時のまとめ

今回大規模にAWS NWを利用するパターンとして、「共有VPC(Shared VPC)」、「Transit Gateway」、およびおまけとして「Transit VPC」の紹介を実施しました。

2022年3月現在、このNW構成にしておけば大丈夫というものはありません。
(強いて言うのであれば、Transit Gateway)

また、どのNWを利用するケースにおいても今後の拡張を考慮した設計が必須となります。この辺の設計が必要なところがNWは難しい、と思ってしまう要因なのかなと感じています。

本記事が皆さんのNW設計において参考になれば幸いです。

次回は大規模NWを利用する問題となる名前解決について記載したいと思います。では次の記事でお会いしましょう。

関連コラム

お問い合わせ

【著者プロフィール】

園田 一史(そのだ かずし)

伊藤忠テクノソリューションズ株式会社 クラウドアーキテクト

AWSの導入・運用支援サービス「CUVIC on AWS(キュービック オン エーダブリューエス)」の運営を担当。大規模DCのNW設計・構築、また国産IaaS型クラウドサービスの企画・導入・設計を歴任。物理・仮想基盤の設計、構築経験を活かし、AWSの導入・構築の支援をサポート。2019年、2020年APN Ambassadorに選任。

園田 一史(そのだ かずし)

TOP>コラム一覧>はじめてのAWS NW(その3)

pagetop