【レポート】ネットワークデザインパターン Deep Dive #AWSSummit

こんにちは、岩城です。

2019年6月12日(水)〜2019年6月14日(金)の 3 日間にわたり、 千葉県の幕張メッセにて AWS Summit Tokyo 2019 が開催されています。

こちらで講演されたセッション「ネットワークデザインパターン Deep Dive」を聴講しましたのでレポートします。

概要

本セッションでは、お客様からよくご相談いただくネットワーク関連の課題とその解決方法にフォーカスし、ネットワークデザインパターンとしてご紹介します。新たなワークロードについてこれから構成検討する方、既存構成を最新化したいお客様に最適です。基本的なサービスの紹介は省略しますので、本セッションの前に予定されている「AWS ネットワークの構成パターンと設計のポイント」への参加も合わせてご検討ください。

スピーカー

  • アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト
    • 益子 直樹

※敬称略

レポート

概要

  • 参加者
    • インフラのネットワーク設計/運用担当者
    • インフラの方針設計者
  • ゴール
    • 新規構築の場合、ネットワーク構成のベストプラクティスの理解
    • 運用中の場合、運用負荷の軽減

ネットワーク設計に重要なサービスのおさらい

  • VPC
  • Direct Connect(以降、DX)
  • Route53
  • Transit Gateway(以降、TGW)

歴史を追いながら理解する

  • 各サービスのが生まれた経緯を理解することは良いアーキテクチャに結び付けられる

VPCリリース

  • 2013-12にリリース
  • VPCでより隔離されたセキュアな空間が利用可能に

VPC Peeringリリース

  • 2014-3にリリース
  • VPC相互にデータ交換可能に
  • 共有サービス提供VPCパターン
    • 注意点
    • 仮に10個のVPCをフルメッシュで接続すると45個のVPC Peeringが必要に

海外のリージョンに接続 Inter-Region VPC Peeringリリース

  • 2017-11にリリース
  • 海外支社からもデータ連携したい
    • オレゴンリージョンから東京へ

オンプレミスと閉域接続(DX)

  • 専用線でオンプレと接続したい
  • 親アカウントでDXを接続し、各VPCのVGWに接続する
  • VPC Peeringを外すとVPC同士の折返し通信がオンプレルータで発生する  

DX Gateway(以降、DXGW)をリリース

  • 2017-11にリリース
  • DX private VIF の本数を整理したい
    • DXGWにより1個のVIF:N個のVPCを接続可能に
    • 当時はマルチアカウント対応されていなかった

DXGW+海外リージョン

  • オンプレから直接海外のVPCに接続できる
    • 折返し通信を防ぐためにInter-Region VPC Peeringを設定

DXGWマルチアカウント対応

  • 2019-3にリリース
  • 海外リージョンでも利用可能

ここまでの整理

  • 長所
    • マルチアカウントで
    • 海外リージョンを含めて
    • 完全閉域のネットワークを設計可能
  • 短所
    • 構成が複雑になりがち

TGWリリース

  • 2018-11にリリース
  • TGWは折返し通信可能、VPC Peering可能
  • この時点ではDXによるオンプレミスへの接続は未対応だった

TGWがDXGWに対応

  • 2019-5にリリース
  • 親アカウントでDXGWを作成、TGWを利用したいアカウントでTransit VIFを作成
  • 現時点で4リージョンに対応

TGW+海外リージョン接続

  • 各リージョンでTGWを作成する
  • 東京リージョンリリース予定

ネットワーク関連でよく頂くご相談

オンプレ/VPCからVPC外のサービスにアクセスしたい

  • 解決したい課題1
    • VPCの中からVPC外のサービスにアクセスしたい
    • DynamoDBやS3等は、VPCエンドポイントのGateway型を使ってアクセス
    • 例えばECR、VPCエンドポイントのインターフェイス型を使ってアクセス
    • 上記2つに対応していない場合は、NAT Gatewayを経由してアクセス
  • 解決したい課題2
    • オンプレミスから直接VPC外のサービスにアクセス
    • VPCエンドポイント未対応のサービスへの接続方法
    • NAT Gatewayは嫌
  • 4つのパターン
    • 1.オンプレ→DX private VIF→VPCエンドポイント(Gateway型)→DynamoDB/S3
      • Gateway型の場合、別途Proxy用のインスタンスが必要
    • 2.オンプレ→DX private VIF→VPCエンドポイント(Interface型)→ECR
      • Proxyなし、直接オンプレからアクセス可能
    • 3.NAT Gatewayや対応していないサービスへのアクセス
      • 共有サービスVPCを作成
      • NLB→共有プロキシ→DynamoDB/S3
      • Private Linkを使って独自にサービスを作成および提供することがdけいる
    • 備考 独自VPCエンドポイントのアクセス制御
      • Interfaceに対してSecurity Groupを設定する
      • ProxyにURLフィルタを設定する
    • 備考 1:Nの共有サービスとして利用可能
      • Private Link1個:N個のVPCに共有サービスを提供可能
    • 4.Public Interfaceによるアクセス
      • オンプレミスからAWSとの物理的な閉域接続を担保しつつVPCを経由せず1HOPでS3にアクセス可能
      • 専有型のDXであればPrivate VIFと同じ物理回線でVIFによる通信可能
      • パブリック・アクセスできないと使えない案

オンプレミス/AWS間のシームレスなDNS設計がしたい

  • 前提:DNS解決の流れについておさらい
    • EC2からRDSのエンドポイントをRoute53にクエリ→Route53からIPアドレス応答→EC2からRDSにアクセス
  • 解決したい課題
    • オンプレミスからAWS上のシステムへの名前解決
    • AWSからオンプレミスのシステムへの名前解決
    • オンプレミスから透過的な名前解決になる設計にしたい
  • Route53のResolverはオンプレミスからのクエリに反応できない
  • 今までの解決策は
    • DNSフォワーダーをVPC内で構築していた

Route53 Resolver Endpointがリリース

  • ポイントは、Inbound EndpointとOutbound Endpoint
  • オンプレミスからVPC内のリソースをDNS Lookup
    • Route53 ResolverのInbound Endpointを設定する
    • オンプレミス側のResolverにはInbouned Endpointへ転送するルートを設定 
  • AWSからオンプレ内のリソースをDNS Lookup
    • Route53のResolverにOutbound転送ルールを設定
      • 例:onpre.com xxx.xxx.xxx.xxx
    • Outbound EndopointからオンプレResolverへ

TGWにおけるDNSクエリ

  • 同一アカウント/同一Transit GatewayのVPC接続の場合
  • 他のVPCにあるリソースのクエリに対しても返ってくる
  • クロスアカウントやVPN接続の場合
    • Resolver Endpointを用意する

オンプレミスとAWS接続を高信頼にしたい

  • 解決したい課題
    • ミッションクリティカルなワークロードを扱いたい
  • 解決策
    • SPOFを排除
    • 費用対効果の観点冗長化する箇所を優先付け
  • TCPセッションは障害時に即時バックアップに引き継がれること
    • データセンターやAZを跨いだ時点で不可能
    • システム全体の正常性の定義を考えなおしてみる
  • Design for Failerの考え方
    • 絶対に落ちないシステムはない
    • 疎結合や水平に展開できるシステムを設計する
  • 費用対効果の観点で冗長化する箇所を優先付け
    • デュアルDXロケーション
    • 同一通信キャリアを利用している場合、異経路にする
    • 異なる通信キャリアを利用し、ラストワンマイルも含めて異経路にする
    • 備考 障害時のみ Internet VPNを利用
      • Backup回線としてインターネットを利用し低コストで冗長化
    • 大阪ローカルリージョンの利用(東京激甚災害を考慮)
      • DXGWはAWSサービス内部で冗長化
      • 大阪OS1、大阪ローカルリージョン間の通信については東京を経由しない設計
    • 海外リージョンの利用
    • 上記以外にも考えられること
      • BFD(Bidirectional Forwarding Detection)
        • 2台の装置間での経路の生存状況を調べ,いち早く障害を検出することを目的とした昨日
      • Link Aggregate
      • DXロケーションの渡りを作る
      • デュアルシステムにする

新サービスへのスムースな移行

  • 解決したい課題  - 既存環境からスムースな移行
  • Classic VPNからSite to Site VPNに移行
    • 移行手順
      • 新しいVPNを作成
      • VPCからVGWをデタッチする(通信断発生)
      • VPCにVGWを作成しアタッチする
      • 古いVGWを削除する
  • Transit VPCからTGWへ移行
    • MigratorTool on EC2を使って移行することが可能
  • 既存VPCからTGWへの移行
    • TGWを作成してVPCと接続
    • DXGWをTransit VIFを使ってTGWにアタッチ
    • VPC宛の経路をPrivate VIFからTransit VIFに変更
    • オンプレ宛をVGWからTransit Gatewayに変更
  • 注意点
    • 事前テストを実施
    • マルチアカウント利用の前提条件を確認しておく

感想

歴史的背景を踏まえつつ、どのようにネットワークに関するサービスがアップデートされて来たか理解できました。 セッションでも言われていましたが、より深い理解のために実際に触りたいと思います。

Transit Gateway好きです!