【レポート】ネットワークデザインパターン 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により１個の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つのパターン
• １．オンプレ→DX private VIF→VPCエンドポイント(Gateway型)→DynamoDB/S3
• Gateway型の場合、別途Proxy用のインスタンスが必要
• ２．オンプレ→DX private VIF→VPCエンドポイント(Interface型)→ECR
• Proxyなし、直接オンプレからアクセス可能
• ３.NAT Gatewayや対応していないサービスへのアクセス
• 共有サービスVPCを作成
• NLB→共有プロキシ→DynamoDB/S3
• Private Linkを使って独自にサービスを作成および提供することがｄけいる
• 備考 独自VPCエンドポイントのアクセス制御
• Interfaceに対してSecurity Groupを設定する
• ProxyにURLフィルタを設定する
• 備考 1:Nの共有サービスとして利用可能
• Private Link１個：N個のVPCに共有サービスを提供可能
• 4.Public Interfaceによるアクセス
• オンプレミスからAWSとの物理的な閉域接続を担保しつつVPCを経由せず１HOPでS3にアクセス可能
• 専有型のDXであればPrivate VIFと同じ物理回線でVIFによる通信可能
• パブリック・アクセスできないと使えない案

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

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

Route53 Resolver Endpointがリリース

• ポイントは、Iｎbound 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好きです！