![[レポート] AWS ネットワークアーキテクチャ 総まとめ！ #NET320 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2019/12/reinvent2019_report_eyecatch.jpg)
[レポート] AWS ネットワークアーキテクチャ 総まとめ！ #NET320 #reinvent
こちらはラスベガスで開催された AWS re:Invent2019のセッション
The right AWS network architecture for the right reason #NET320
のレポートです。
Transit Gateway/PrivateLink などの新サービス登場や 既存サービスのアップデートとともに、 AWSにおけるネットワーク構成の選択肢は増え続けています。
本セッションは、今のAWSにおけるネットワーク構成が網羅されている 良いセッションでした。
本ブログでは、このセッションで出てきた AWSネットワークアーキテクチャ パターンを紹介 していきます。
資料
セッション動画
目次
項目が多いので以下に目次を作成しています。 目次のリンクから気になるアーキテクチャを参照ください。
シングルVPC、マルチVPC
ハイブリッドネットワーク
サービス別(Transit Gateway、PrivateLink)
フラットネットワーク アーキテクチャ (Single VPC)
ネットワークインフラを構築するときに、まず作成するのは VPCです。 その VPCをどのように構成するかは重要です。
本章は 1 VPCでシステムを構築・運用する構成 について紹介します。
Single VPC: シングルアカウント構成
一番シンプルな構成です。 システム領域の分割は サブネットやルートテーブル、NACLなどを用いて行います。
システムの規模が大きくなって使えるIPレンジが無くなってきた…
その場合は VPCの CIDR拡張 が行えます。
Q:VPC のサイズは変更できますか?
はい。既存の VPC を拡張するには、4 つのセカンダリ IPv4 IP 範囲 (CIDR) を VPC に追加します。
– 引用：Amazon VPC よくある質問
↑ は 既存の 10.0.0.0/16 VPCに
Secondary CIDR として 10.1.0.0/16 を追加した構成例です。
Single VPC: マルチアカウント構成 (Resource Access Manager)
1 VPCのシステムを 複数のアカウントで構築・運用 したいケースを考えます。
その場合は AWS Resource Access Manager(RAM) を使えます。
AWS Resource Access Manager (RAM) は、 AWS のリソースを任意の AWS アカウントまたは AWS 組織内で簡単かつ安全に共有できるサービスです。
AWS Transit Gateway、サブネット、AWS License Manager の設定、Amazon Route 53 リゾルバーのルールのリソースを RAM で共有できます。
- このサブネット内のリソースは アカウント
Blueに共有する - あのサブネット内のリソースは アカウント
Purpleに共有する
といった制御ができます。
分割ネットワーク アーキテクチャ (Multi VPC)
ネットワークインフラを構築するときに、まず作成するのは VPCです。 その VPCをどのように構成するかは重要です。
本章は
- 複数 VPCでシステムを構築・運用する構成
- VPC間の接続方法
について紹介します。
Multi VPC: シングルアカウント構成
既存VPC と完全に独立した環境で新規システムを構築したい、要求があったとします。 そういった場合は VPCを複数作成して対応します。
Multi VPC: マルチアカウント構成
大きい組織ですと
- チーム毎にAWSアカウントを作成してアクセス制御を行ったり、
- 事業単位やワークロード単位で独立させたい
ケースが出てきます。
そういったケースには マルチアカウントで対応するでしょう。
VPC間の接続 (VPC ピアリング)
VPC間を接続する シンプルな方法として VPC ピアリング があります。
リージョンや AWSアカウントを跨いた接続のサポート、スケーリングや高い冗長性などが特徴です。
一方で 以下のような欠点もあります。
▼ 「推移的なルーティング」 はできない
VPC A を経由して VPC B から VPC C にパケットを直接ルーティングすることはできません。
– 引用： サポートされていない VPC ピア接続設定
▼ 規模がでかくなるにつれて ピアリング接続の管理が大変になる
(極端な例ですが) 100 VPCをフルメッシュで VPCピアリング接続する場合、 4,950 ものピアリング接続が必要となります。
VPC間の接続 (Transit Gateway)
Transit Gateway によって ネットワークのハブ接続を可能にします。 複数のVPC間で通信を行いたい場合も 1 Transit Gateway をアタッチするだけで実現できます。
また、 Transit Gateway はオンプレミス ネットワークとの接続もサポートしています。
この Transit Gateway でできることは多岐にわたります。 Transit Gateway 固有のアーキテクチャは Transit Gateway 章にて説明しています。
ハイブリッドネットワーク アーキテクチャ (サイト間VPN)
ハイブリッドクラウドの構成で使用される サイト間VPN (Site-to-Site VPN) の接続方法 3種類を紹介します。
サイト間VPN: Transit Gateway
サイト間VPNを Transit Gateway(TGW) を用いて構築します。 TGW はリージョン単位のサービスなので、 リージョン内の各VPCと接続、ルート制御が可能です。
また、本セッションでは言及されていませんでしたが、 TGWを用いたサイト間VPNの接続オプションとして、高可用性・高パフォーマンスな Accelerated Site-to-Site VPN が re:Invent2019後から選択可能になりました。
[速報] AWS Accelerated Site to site VPN Connectionsがリリースされました！ #reinvent
サイト間VPN: 仮想プライベートゲートウェイ
仮想プライベートゲートウェイ (Virtual Private Gateway: VGW) を使って オンプレミスとVPCを 1対1接続する構成です。
サイト間VPN: ソフトウェアVPN on EC2
EC2インスタンス上に Openswanなどの VPNソフトウェアを起動してオンプレミスと接続する方法です。
ハイブリッドネットワーク アーキテクチャ (Direct Connect)
ハイブリッドクラウドの構成で使用される Direct Connect(DX) の接続方法 3種類を紹介します。
DX: 仮想プライベートゲートウェイ
Private Virtual Interface(VIF) を VPCにアタッチした Virtual Private Gateway (VGW) へ接続 する方法です。
DX: Direct Connect Gateway + 仮想プライベートゲートウェイ
Private VIFを Direct Connect Gateway(DX Gateway) へ接続します。
DX Gateway と 任意リージョンのVPC が接続できます ( 10 VPCまで )
DX: Direct Connect Gateway + Transit Gateway
DX Gateway と TGW を用いる方法です。 1 DX Gateway につき 3 TGWまで 接続可能です。
ハイブリッドネットワーク アーキテクチャ (IP重複対策)
オンプレミスとAWSで重複する IPアドレスが存在するときの対策です。
AWS → オンプレミス 向き (PrivateLink + NLB)
PrivateLink + Network Load Balancer で実現します。 CIDR が 重複しないNAT用 VPC を準備します。
- アクセス元VPCに PrivateLink を配置
- NAT用 VPCに Network Load Balancer を配置
- Network Load Balancer の IPターゲット にオンプレミスサーバーのIPアドレス を指定
オンプレミス → AWS 向き (PrivateLink + NLB)
同じく PrivateLink + Network Load Balancer で実現します。 CIDR が 重複しないNAT用 VPC を準備します。
- NAT用 VPCに PrivateLink を配置
- アクセス先VPCに Network Load Balancer を配置
- Network Load Balancer の IPターゲット に AWSの EC2やRDSの IPアドレス を指定
ハイブリッドネットワーク アーキテクチャ (DNS)
ハイブリッドネットワークにおける 名前解決(DNS) の実装方法についてです。 2018年にローンチした Route 53 Resolver が活躍します。
Route 53 Resolver
Route 53 Resolver の以下 3つの構成要素を作成して実現します。
- Inbound Endpoint: オンプレミス環境から VPC向けの名前解決を行うためのエンドポイント
- Outbound Endpoint: VPC環境から オンプレミス向けの名前解決を行うためのエンドポイント
- Resolver Rules: フォワーディングのルールを定義
Route 53 Resolver の詳細については 以下 Black Belt などがとても参考になります。 参照ください。
Transit Gateway
Transit Gateway(TGW) によって ネットワークのハブ接続を可能にします。 複数のVPC間で通信を行いたい場合も 1 TGW をアタッチするだけで実現できます。
本章ではセッションで紹介された TGWルートドメインを活用したアーキテクチャ を記載していきいます。
Shared service VPC
共有VPC (Shared services VPC) の役割をもたせるアーキテクチャです。
- App1, App2, App3 は 相互にアクセスできない
- App1, App2, App3 は Shared services VPC と オンプレ環境 にアクセスできる
上記 ルールを満たすために、ルートテーブルを 2種類作成しています。
Bump-in-the-wire VPC
通信を 特定のセキュリティアプライアンス経由で流したい、要求を実現するアーキテクチャです。
- App1, App2 から発信された通信は TGWを経由して Bump-in-the-wire VPC へ向かいます
- Bump-in-the-wire VPC のメインルートテーブルの デフォルトゲートウェイは セキュリティアプライアンスのENI なので、 App1, App2 からの通信は セキュリティアプライアンスへ向かうことになります
- セキュリティアプライアンスがあるサブネットのルートテーブル により、 App1, App2 の所望の通信先へと向かいます
その他 (TGW詳細)
本セッション外ですが、 Transit Gateway の詳細については以下のセッションや Transit Gateway Reference Architecture が参考になります。ぜひ参照ください。
[レポート] 新サービスの紹介も！複数 VPC における Transit Gateway のリファレンスアーキテクチャ #NET406 #reinvent
PrivateLink
AWS PrivateLink は AWSでホストされているサービスに、安全にアクセスできる機能です。 TCP経由 の通信のみサポートしています。
VPC ピアリングや Transit Gateway と違って、 PrivateLinkは 特定のポート、特定のIPアドレス のサービスを利用するために、 VPC間に通信の経路を作成する用途で使用されます。
ハイブリッドネットワーク アーキテクチャ (IP重複対策) で話したとおり、IP重複の対策として利用できます。
VPCエンドポイントの集中化
PrivateLinkを利用したアーキテクチャとして、 VPCエンドポイントの集中化 が紹介されています。
- VPCエンドポイントと
- 別名登録のためのRoute 53 プライベートホストゾーン
を前述の Shared Service VPC 構成の 共有VPCに集めて設定します。
他の VPCと Shared Service VPC間でプライベートホストゾーンを共有 できるようにするために、 関連付けを行います。
集中化させることで、エンドポイントの設置台数が減り PrivateLink関連のコストを削減することが出来ます。
おわりに
以上、 The right AWS network architecture for the right reason #NET320
のレポートでした。
各アーキテクチャの長所・短所やアーキテクチャを決定する際のポイントなど、 セッションでは言及されています。気になった方はぜひセッションの動画も御覧ください。
各アーキテクチャを整理・理解することでAWSのネットワークサービスについて広く理解が得られました。
![[登壇レポート] VPC間の接続方法を整理してみた #自治体クラウド勉強会](https://images.ctfassets.net/ct0aopd36mqt/6WDF8DnUY0lRO6CiIHDszj/395fdc3b14a82a82ca9f794ee9494118/amazon-vpc.webp)
