背景・目的
- 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に転送するように設定する。
- 名前解決と通信
- オンプレミスのClientは、オンプレミス内のDNS Resolverに対して、VPC内のEC2のIPアドレスを問い合わせる。
- オンプレミスのResolverは、Route53 Resolverに問い合わせる。（InBound Endpointにアクセス）
- Route53 ResolverはEC2のIPアドレスを知っているので名前解決して、オンプレミスのResolverに返却する
- オンプレミスのResolverは、ClientにIPを返す
- Clinetは、EC2にトラフィックを投げる。
- 準備
-
VPC内リソースからオンプレミスにLookup(Out-Bound)
- 準備
- Route53 Resolverの転送ルールにオンプレミスのDNSを設定
- 名前解決と通信
- VPC内のEC2からIn-Bound Endpointを利用してRoute53 Resolverに名前解決する。
- ResolverはOut−Boundの転送ルールをLookup。その結果転送ルールに該当するので、OutboundEndpointに抜ける。
- Out-Bound EndpointからVGW をとおりオンプレミスのDNS ResolverにLook upする。
- オンプレミスのDNS ResolverはIPアドレスを返す。
- VGW→Outbound Endpoint→ Route53 Resolver→In-Bound Endpoint→EC2へとLookupしたIPアドレスを返す。
- EC2→オンプレミスのリソースへアクセスする。
- 準備
オンプレミス/AWS間接続を高信頼にしたい
- デュアルDxロケーション
- Equnixとアット東京の利用など
- 同一キャリアで異経路設計
- 異なる通信キャリア
- オンプレミスとDxロケーション間の高信頼化
- 大阪ローカルリージョン
- 大阪のDxロケーションを併用する。
- DxGWは、AWSで冗長化されている。
- 海外リージョン
- 上記と同じように海外リージョンを利用する。
考察
TBD