[解説] AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)

AWS運用自動化サービス「Cloud Automator」

こんにちは、PS課 佐竹です。
今回は、re:Inventのセッション動画を(日本語で)解説したいと思います。

はじめに

AWSのre:Invent 2018ではネットワーク設計が覆るいくつもの機能がリリースされました。
「それを1つずつ追っていくのは辛いなあ、誰かまとめてくれないかな~」なんて思っていたら、こんなセッション動画がありました。


AWS re:Invent 2018: Advanced VPC Design and New Capabilities for Amazon VPC (NET303)

「これめっちゃええやんけ!(関西弁)」

と思ったので、今回は本セッション動画の内容のご紹介となります。
「英語だと読み解くのが辛い!」という方もいらっしゃれば「動画が長くて辛い!」という方もいらっしゃるでしょう。そこで、今回はこの動画から「必要なエッセンス」だけを抜き出した「要チェックなポイントだけ」をご紹介する記事となっております。

以前のAWSネットワーク環境

最初に、「以前の」AWS環境のネットワーク構成がプレゼンテーションされます。上記の図がそれになります。この図について、少々解説を入れます。

  1. 中心にAWSがあり、AWSの中には「VPC」と「Subnet」がAvailability Zoneを分割して存在する
  2. 左下に図示されているように、各Subnetには「Route Table」の設定がある
  3. VPCの中の「Instance」は、「NAT-GW(Gateway)」及び「IGW(Internet Gateway)」を通じてInternetと通信を行う
  4. 右下には、オンプレミスとの接続のためにAWS側の接続ポイントとして「VGW(Virtual Private Gateway)」が、それらをつなぐ間の線として「Direct Connect」及び「DXGW(Direct Connect Gateway)」や「VPN Connection」が利用される
  5. 中心のVPCと、別で存在する「VPC-B」とは「VPC Peering」で接続が可能で、VPC Peeringには「Region」を跨いで接続可能な「Inter Region VPC Peering」がある
  6. VPCのログは「VPC Flow Logs」として「Cloud Watch Logs」に出力される(※補足:現在はS3にもPutできます)
  7. 「S3」や「DynamoDB」「Lambda」は「VPCE(VPC Endpoint)」を通じてVPC内部からインターナルな接続で利用が可能
  8. 「VPCE」が無いVPC外にあるサービス(SNS、SQS、IoT等)は、「IGW」を通じてインターネットのサービスとして利用する
  9. 左上にあるように、「NLB(Network Load Balancer)」を利用することで、「PrivateLink」として他のAWSアカウントのVPCにあるサービスを、VPC Peeringなしに利用が可能

ざっと書きましたが、「今までのAWSのネットワーク」がこの絵一枚で表現されており、非常にまとまっていてわかりやすい図となっております。

AWS PrivateLink, Additional Endpoints

1発目、ちょっと地味ですが、PrivateLinkとしてEndpointが増えています。以下、現時点でのEndpointの一覧を記載します。

Service Name Owner Type
aws.sagemaker.ap-northeast-1.notebook amazon Interface
com.amazonaws.ap-northeast-1.cloudformation amazon Interface
com.amazonaws.ap-northeast-1.cloudtrail amazon Interface
com.amazonaws.ap-northeast-1.codebuild amazon Interface
com.amazonaws.ap-northeast-1.config amazon Interface
com.amazonaws.ap-northeast-1.dynamodb amazon Gateway
com.amazonaws.ap-northeast-1.ec2 amazon Interface
com.amazonaws.ap-northeast-1.ec2messages amazon Interface
com.amazonaws.ap-northeast-1.elastic-inference.runtime amazon Interface
com.amazonaws.ap-northeast-1.elasticloadbalancing amazon Interface
com.amazonaws.ap-northeast-1.events amazon Interface
com.amazonaws.ap-northeast-1.execute-api amazon Interface
com.amazonaws.ap-northeast-1.kinesis-streams amazon Interface
com.amazonaws.ap-northeast-1.kms amazon Interface
com.amazonaws.ap-northeast-1.logs amazon Interface
com.amazonaws.ap-northeast-1.monitoring amazon Interface
com.amazonaws.ap-northeast-1.s3 amazon Gateway
com.amazonaws.ap-northeast-1.sagemaker.api amazon Interface
com.amazonaws.ap-northeast-1.sagemaker.runtime amazon Interface
com.amazonaws.ap-northeast-1.secretsmanager amazon Interface
com.amazonaws.ap-northeast-1.servicecatalog amazon Interface
com.amazonaws.ap-northeast-1.sns amazon Interface
com.amazonaws.ap-northeast-1.ssm amazon Interface
com.amazonaws.us-east-1.codebuild-fips amazon Interface
com.amazonaws.us-east-1.sagemaker.runtime-fips amazon Interface

なお、一番下の2つは”us-east-1″等で表示されますが、Tokyo Regionには表示されないものです。
本リリースのブログはこちらになります。またボーナスとして以下のリリースも掲載されました。

Amazon VPC Sharing

次にVPC Sharingです。これは素晴らしい、「やっと来たか」という機能ですね。

以前は上記の図の通り、AWSアカウントが異なるVPCをそれぞれVPC Peeringで接続し、お互いにやり取りをしていました。

今後は、VPC同士はそれぞれをPeering接続するのではなく、別のアカウントであっても「VPCのCIDRを共有して」利用することが可能になります。これがVPC Sharingです。このために新しい概念として「Owner」と「Participant」という2つの言葉が登場しました。VPC Sharingについては「こちらのブログ記事」に技術的な制限などが記載されてますので合わせて参照してください。

動画では「何故、(複数のAWSアカウントを利用する前提において)VPCをシェアするのか」について4つの理由が説明されていました。

  1. IPのCIDRアドレスをPeering利用時より減らせる
  2. VPC Peering不要で、お互いに疎通が可能になる
  3. 役割を分担することで、VPCを中央で管理できる
  4. AWSアカウントをまたぐVPC Peeringは同AZでもネットワーク通信料が発生するがシェアすると同AZでは発生しない

これら4つのメリットにより、今後はVPC Peeringではなく、VPC Sharingがネットワーク設計において前提となってくるのではと思われます。公式のドキュメントはこちらになります。

AWS Global Accelerator

AWS Global Accelerator はグローバルなリソース展開を後押しするサービスで、様々な国(リージョン)のそれぞれのエンドユーザーのパフォーマンスを向上させるために用意されました。

上の絵は、各Regionごとに構築されたAWSのサービス(ELBとEC2で構成されている)を1つのGlobal Acceleratorで提供している状態です。以下に、3つのポイントを記載します。

  • ネットワークは、Global Acceleratorに入った後は、AWSの中を通り経路が最適化される(Publicなインターネットより信頼性が高いネットワークを通過します)
  • クライアントとの接続状態を維持することが可能
  • (2つの)静的なAnycast IPアドレスがAWSのエッジロケーションから払い出される

今までグローバルなサービスを運用する場合に、各国のエンドユーザーに安定したパフォーマンスを届けるのは難しい問題だったかと思われますが、本サービスの登場で、それが可能となったばかりでなく、AnycastのIPアドレスが2つ付与され固定されるという恩恵にも預かれるようになりました。

またボーナスとして以下のリリースが掲載されました。

AWS Client VPN

AWS Client VPNは、AWSがマネージするClient向けのVPN接続サービスです。

今までAWSが提供してきた(歴史のある)VPN接続は、VGW(Virtual Private Gateway)とCGW(Customer Gateway ※Global IPを保持した物理ルータ)を構築し、その間に2本のIPsecのトンネルを張るものでした。この接続はSite-to-Siteのみが提供されており、ClientがVPN接続をする形式はサポートされていませんでした。

この度紹介されたのは、↑の図にある通りClient-to-Siteの形式です。VPCに対して、Client VPNのEndpointをアタッチすることにより、Open VPN ClientとのTLS-VPN接続を確立します。AWS Client VPNは「こちら」のSlideshareの50ページ目からも掲載があります。

BYOIP

BYOIP(Bring Your Own IP)は、AWSにGlobal IPを持ち込み利用することができるリリースです。今までElastic IPはAWSが取得しているGlobal IPから選択するしかありませんでしたが、このリリースにより、既に取得済のGlobal IPをElastic IPとして利用が可能となります。本リリースがGAしたのは、2018年10月23日のことでre:Inventに先駆けてリリースされておりました。

注意点としては、現状日本リージョンでは対応しておらず、アメリカでの利用のみとなっている機能になります。

Transit GW(Transit Gateway)

最後に満を持して登場です。Transit Gateway(TGW)は、今回のリリースの中で、最も既存のネットワーク構成に影響を与えるリリースです。TGWは、「VPCとAWS利用者の間に存在するネットワークのハブ」としての機能を持つゲートウェイです。

上の図では、VPC Peeringが運用上難しいものだという説明がなされています。VPCが5つあり、フルメッシュでVPC Peeringを行う場合、組み合わせとして5C2=10通りのペアができます。よって、線は10本です。これが6、7とVPCの数が増えていくと、Route Tableの設定などが破綻しはじめます。10個のVPCがあれば、フルメッシュでは10C2=45通りもの組み合わせが存在しますが、45のPeering設定はかなり現実的には厳しく、VPCの数が20、30、100…となってくると、もはや現実的な設計とは言えないでしょう。またVPCのネットワークにも「制限(上限)」があり、これらのルールに抵触して頭打ちを迎えることもあり得るでしょう。例えば1 つの VPC でのピアリング接続の上限は125 まで、等です。制限については「こちら」のドキュメントに記載があります。

これを解決するにあたり、Transit用のVPCを構築し、VPCをハブとして運用する回避策がありました。しかし、Transit VPCの管理保守運用が必要であることや、DXとの兼ね合いなども考えると、ネットワーク設計は複雑性を増します。

またDXはDXGWがあるものの、VPNコネクションにおいては上図のようにVPCごとにコネクションを作成し、接続する必要がありました。つまり、VPCが3つあれば、VPNのコネクションは3つ必要になってきます。VPCが増えれば増えるほど、比例して手間が増えていました。

そこで、TGWの登場です。先ほどの図と異なり、オンプレミスと、AWSの各VPCの間に「TGW」が存在しています。今後のネットワーク設計では、TGWにさえ接続すればTGWがハブ(中心)となり、各VPC間の通信を制御してくれるようになります。これにより以下のメリットが享受できます。

  1. 各VPC間の通信においてVPC Peeringが不要となる
  2. 各VPCとオンプレミス間の通信において、VPC毎のVPNコネクション接続が不要となる

TGWの利用にあたっては、Route Tableとして新しい用語が登場しています。「Attachment」と「Associations」と「Propagations」です。

  • Attachment : VPNもしくはVPCからTGWへのアタッチ
  • Associations : どこのVPNもしくはVPCから接続が来たのか(From)
  • Propagations : どこのネットワークに送るか(To)

この図で言うと、「X」「Y」「Z」「Q」などと記載がある部分が「Attachment」を示しています。以下、合わせてブログ記事と公式ドキュメントのリンクをご紹介します。

上記FAQの最初に記載がありますが、TGWは東京リージョンではまだご利用頂けません。

AWS Transit Gateway is available in AWS US East (Virginia), US East (Ohio), US West (Oregon), US West (Northern California), EU (Ireland) and AsiaPacific (Mumbai) AWS Regions with support for other regions coming soon.

と記載されていますので、もうすぐにでも登場してくれるかと想像していますが、非常に待ち遠しい機能ですね。加えてですが、1つ目のブログには以下の記載がある通り、現在TGWがアタッチできる先は、VPCとVPNのみとなります。

Direct Connectについては2019年の早い時期に対応を予定しています。

DXについても対応が待ち遠しいですね。既存のDXGWとの兼ね合いも気になるところです。

まとめ

まとめです。本ブログ記事では、Advanced VPC Design and New Capabilities for Amazon VPC (NET303)を紹介するとともに、その中で紹介されている以下のリリースについて掘り下げました。

  • AWS PrivateLink, Additional Endpoints:VPC Endpointに対応したサービスが増えました
  • Amazon VPC Sharing:VPCをAWSアカウントまたぎでシェアして利用可能になりました
  • AWS Global Accelerator:静的な2つのエニーキャストIPが付与されるグローバル展開を後押しするサービスが提供されました
  • AWS Client VPN:AWSがマネージするClient-to-SiteのVPNサービスが登場しました
  • BYOIP:自社で保持しているGlobal IPがAWS内に持ち込めるようになりました
  • Transit GW:AWSとの接続におけるハブとしてTransit Gatewayがリリースされました

これらのリリースにより、ネットワーク設計は今までとは大きく異なるものになってくると想像されます。特に大きく影響を与えるのは「TGW」と「VPC Sharing」でしょう!2019年は、新しいネットワークサービスを利用した設計でVPCを構築したり、既存のネットワークを大きく見直したりする案件が増えるだろうと考えています。が、まずはTGWの東京リージョン対応に期待したいところです。

ここまでお読み頂きありがとうございました。

AWS運用自動化サービス「Cloud Automator」