AWS ネットワークデザインパターンDeep Diveの整理

背景・目的

• AWS Summit Tokyo 2019の「ネットワークデザインパターン Deep Diveの内容を整理する。

内容

Overview

• 歴史を追いながら説明されている。背景などを把握しやすい。

歴史

• 2013/12 VPCリリース
  • セキュアな空間が利用可能になった
• 2014/3 VPC Peeringリリース
  • VPC間で通信可能
  • 同一アカウント、別アカウントのVPC間で通信可能になった。
  • 1ホップまで通信可能。（2ホップはNG)
    • VPCの数が多くなると複雑になる
• 2017/11 Inter-Region Peeringリリース
  • 海外のリージョンに接続が可能になる。(リージョン間通信）
• 2017/11 Direct Connect Gatewayをリリース
  • Private VIFとVGWが1:1だったものが、DxGWをはさむことで1:Nになり、オンプレ-AWS間のPrivate VIFが1本に集約することが可能になる。
  • 同一アカウントのみ（クロスアカウントは不可）
  • 海外リージョンに抜けられる。（オンプレミスから1ホップで接続可能）
• 2018/11 Transit GWがリリース
  • Transit Gatewayは各VPC内のENIに対して通信が可能になる。
  • 折返し通信が可能になる。これによりVPC Peeringが不要になる。
  • Transit GWはリージョンサービスである。
  • Direct Connect対応ができない。
• 2019/3 Direct Connect Gatewayのマルチアカウント対応リリース
  • DxGWが別アカウントのVGWに接続可能
  • この時点でマルチアカウント、マルチリージョン含めて完全閉域NWの通信が可能
• 2019/5 Transit GatewayがDirect Connect Gateway対応された
  • Transit GatewayようにTransit VIFを作成。
  • Dxは従来どおり、DxGWに接続。DxGWからTransit GWに接続し各VPCのENIに接続する。

ユースケース

オンプレミス-VPC内からVPC外サービス(S3等)にアクセスしたい

Source	Direct Connect接続方法	経路	Target	備考
オンプレミス	Private VIF	VPC内のProxyを介してVPCe(GW型)	DDB	オンプレから直接アクセスできないので、Proxyを介する。
オンプレミス	Private VIF	VPCe(I/F型)	DDB以外のVPCe対応サービス	Proxyは不要。直接アクセス可能
オンプレミス	Private VIF	独自VPCe(PrivateLink接続)	VPCe未対応サービス	対応してないものについて、共有サービスVPCとして、NLB＋EC2+NATGWの構成でPrivateLinkでEndpointとして提供可能。 ※NATGWを使うのはパブリックIPが必要なため。 複数のVPCに提供することも共有サービスとして提供可能。
オンプレミス	Public VIF	VPCは通らない	VPCe未対応サービス	パブリックIPをつかってアクセス
オンプレミス	Public VIF	VPCは通らない	別リージョンサービス	同上

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

• 解決したい課題
  • オンプレミスからAWS上のシステムへの名前解決はどうすればよいか？
  • その逆の名前解決は？
  • 透過的な名前解決になる名前解決にしたい

Route53 Resolver Endpoint

• オンプレミスからVPC内リソースへLookup(In-Bound)

  • 準備
    • Route53 ResolverのIn-Boundのエンドポイント（VPC内）を設定する。
    • オンプレミスのDNS ResolverにInbound Endpointに転送するように設定する。
  • 名前解決と通信
    1. オンプレミスのClientは、オンプレミス内のDNS Resolverに対して、VPC内のEC2のIPアドレスを問い合わせる。
    2. オンプレミスのResolverは、Route53 Resolverに問い合わせる。（InBound Endpointにアクセス）
    3. Route53 ResolverはEC2のIPアドレスを知っているので名前解決して、オンプレミスのResolverに返却する
    4. オンプレミスのResolverは、ClientにIPを返す
    5. Clinetは、EC2にトラフィックを投げる。

• VPC内リソースからオンプレミスにLookup(Out-Bound)

  • 準備
    • Route53 Resolverの転送ルールにオンプレミスのDNSを設定
  • 名前解決と通信
    1. VPC内のEC2からIn-Bound Endpointを利用してRoute53 Resolverに名前解決する。
    2. ResolverはOut−Boundの転送ルールをLookup。その結果転送ルールに該当するので、OutboundEndpointに抜ける。
    3. Out-Bound EndpointからVGW　をとおりオンプレミスのDNS ResolverにLook upする。
    4. オンプレミスのDNS ResolverはIPアドレスを返す。
    5. VGW→Outbound Endpoint→ Route53 Resolver→In-Bound Endpoint→EC2へとLookupしたIPアドレスを返す。
    6. EC2→オンプレミスのリソースへアクセスする。

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

1. デュアルDxロケーション
   1. Equnixとアット東京の利用など
2. 同一キャリアで異経路設計
3. 異なる通信キャリア
   1. オンプレミスとDxロケーション間の高信頼化
4. 大阪ローカルリージョン
   1. 大阪のDxロケーションを併用する。
   2. DxGWは、AWSで冗長化されている。
5. 海外リージョン
   1. 上記と同じように海外リージョンを利用する。

考察

TBD

参照

ネットワークデザインパターン Deep Dive