【講演メモ】ネットワークデザインパターンDeep Dive

AWS professional勉強のため講演をまとめたメモです。
ご参考まで。

資料　https://pages.awscloud.com/rs/112-TZM-766/images/B1-04.pdf
動画　https://www.youtube.com/watch?v=6I7jQOLOiWY

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

• VPCリリース
• 共有サービス提供VPCパターン
  • VPCピアリング
• 海外のリージョンに接続 Inter-RegionPeering
  • AzureのグローバルVNETピアリング相当
• Direct Connect
  • 1つのPrivate VIFに対してVGW
• Direct Connect Gateway 2017-11
  • 1つのPrivate VIFで複数VPCに接続可能
  • マルチアカウントに非対応だった
• Direct Connect Gatewayマルチアカウント対応
  • 海外リージョンにおいてもクロスアカウント可能に
• Direct Connect Gateway + 海外リージョン
• Transit Gateway 2018-11
  • 各VPCにENIを一つ。
  • 折返し通信可能。
  • この時点では、Direct Connect未対応
• Transit GatewayがDirect Connect対応 2019-5
  • Transit Gateway用にTransit VIFを作成
  • 東京リージョン未対応（2020年時点では対応）
  • https://aws.amazon.com/jp/transit-gateway/faqs/

ネットワーク関連でよくある相談

1. オンプレミス/VPN内からVPC外サービスへアクセスしたい

• VPN Endpoint GW型
  • DynamoDB, S3（当時も2020年8月時点も2サービスのみ）
  • https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-endpoints.html
  • オンプレミスから直接Proxy on EC2が必要。
• VPC Endpoint Interface型
  • DynamoDB, S3以外のサービス
  • VPCエンドポイント未対応サービスへの接続方法は？
    • Endpoint Interfaceを使用しないでDirect Connect Public VIF経由で接続する方法もある。（ハードル高いな。）
• NAT GW経由
  • 共有サービスVPC
  • PrivateLink（クライアントVPC内）→Proxy on EC2→ NAT GW→Cognito
• Public Interfaceによるアクセス
  • Public IPを使う場合はだめ。（AzureのMSFTピアリング相当）

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

• DNS解決の流れについておさらい
  • Route53のIPアドレス VPC CIDR+2のアドレスが提供される
  • オンプレミスから繋ぐ場合にはどうなる？
  • AWSのリソースからオンプレミスのDNS
  • オンプレミスから見て意識させないようにしたい。
  • Route53はAWSリソースからしか名前解決しない。
• 解決策　Route53 Resolver Endpoint
  • Inbound Endpoint（オンプレ→AWSを名前解決）
    • オンプレのDNS Resolverで、aws.example.comについてはInbound Endpointへ転送するように設定しておく
  • Outbound Endpoint（AWS→オンプレミスを名前解決）
    • Outbound転送ルールにオンプレミスのDNSレコードを登録しておく。
  • Transit GatewayにおけるDNSクエリ
    • 同一アカウント同一Transit GatewayのVPC接続
      • Route53 Resolver Endpointは不要
    • クロスアカウント
      • Route53 Resolver Endpointが必要
        -（公開資料に記載）

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

• 解決したい課題

オンプレミス/AWS間の冗長化・高信頼設計
よくある要求仕様
　TCPセッションは障害時に即座にバックアップ回線に引き継がれること。
　Design for failureの考え方・・・絶対に

落ちないシステムはない。
費用対効果の観点で冗長化する箇所を優先付け（優先度は1が高、5が低）

• 1 デュアルDirect Connectロケーション
  • 東京リージョン（Equinix TY2), 東京@CC1にそれぞれ置く
  • ロケーションというのがあるんですね。
    アット東京 CC1 中央データセンター、東京、日本 アジアパシフィック (東京)
    　　Chief Telecom LY、台北、台湾 アジアパシフィック (東京)
    　　Chunghwa Telecom、台北、台湾 アジアパシフィック (東京)
    　　Equinix OS1、大阪、日本 アジアパシフィック (東京)
    　　Equinix TY2、東京、日本 Equinix TY2、TY6 – TY8、東京アジアパシフィック (東京)
    　https://aws.amazon.com/jp/directconnect/features/
• 2 同一キャリアで別経路を用意する
• 3 異なる通信キャリアを利用
• 4 大阪ローカルリージョンの利用
  • Direct Connect GatewayはAWS側で冗長されているので、SPOF(single point of failure)にならない。
• 参考　障害時のみInternet VPNを利用
• 5 海外リージョンの利用

移行

　こちらは割愛。