0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

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

Posted at

背景・目的

  • 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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?