この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本記事は、AWS re:Invent 2018 のセッション 「NET402 - [NEW LAUNCH!] AWS Transit Gateway and Transit VPCs, Reference Architectures for Many VPCs」のセッションレポートです。
In this session, we will review the new AWS Transit Gateway and new networking features. We compare AWS Transit Gateway and Transit VPCs and discuss how to architect your accounts and VPCs. This session will be helpful if the developers have been let loose, and you are planning lots of VPCs or accounts. How should you connect them; what limits do you need to be aware of; and how does routing work with many VPCs? We dive into the details of recent launches and how to work with concepts like Transit VPCs, account strategies, scaling services, using firewalls, and direct connect gateways to solve problems of many VPCs.
- スピーカー
- Nick Matthews - Principal Solutions Architect, AWSk
動画
スライド
[slideshare id=124457557&doc=new-launch-aws-transit-gate-c1318128-b12a-4b98-94e3-cedb040e27ec-2132178208-181130035301]
レポート
VPC 管理の差
- 作りやすさ
- アクセスモデル
- 多用なオーナーシップ
課題
従来は VPC 単位で VPN や DX で接続していましたが、VPC が増えるとコネクション増え、複雑に。さらに VPC 間をピアリングしてようものなら、管理は複雑だし、VPC が追加される度に相互で設定が必要で大変でした。
従来は Transit VPC という考え方がありました。
Transit VPC の図と比較すると、AWS Transit Gateway が如何にシンプルなコネクションになるかが判りますね。
Transit VPC のメカニズム
Transit Gateway を理解するには、Transit VPC のメカニズムを知る必要があるため、まず Transit VPC の説明がありました。
Transit VPC: ルーティング
Transit VPC に設置した VPN インスタンスが各 VGW に BGP でルート情報を伝播することで、Transit VPC を介して接続先同士の VPC 間通信が出来ます。
VPC ピアリングだと何故 Transit できないの？
トラフィックは、VPC 内のネットワークインターフェイス上で発信または終端する必要があるため出来ません。
Transit VPC: 可用性
BGP と Dead Peer Detection（DPD）は障害を検知し、VGW のルートは自動的にフェイルオーバーし、もう一方のトンネルを通ります。
Transit VPC: パフォーマンス
Transit Gateway のために、これを知る必要がある。とのことです。
- VPNインスタンスはすべてのトラフィックを転送する必要があり、最大値はインスタンスサイズに基づく。M4 や C4 ファミリーで 1〜3 Gbps
- VGWは、アウトバウンドトラフィックに対して1つのトンネルのみを選択する
- VGWは、任意のトンネルまたは接続でパケットを受け入れる
Transit VPC: セキュリティサービス
AS パスの prepend 属性で自動切り替えをコントロールしています。
Transit Gateway
Transit Gateway の紹介
- ルータは Regional
- VPN と AWS Direct Connect を集中管理
- （AWS Direct Connect は 2019/Q1 対応予定）
- VPN と AWS Direct Connect を集中管理
- スケーラブル
- アカウント間の数千の VPC
- 多くの VPN 接続でトラフィックを分散させる
- 柔軟なルーティング
- サブネット内のネットワークインタフェース
- ルーティングによるセグメント化と共有の制御
AWS HyperPlane と AWS Transit Gateway
- アタッチメント
- AZ 毎に 1 つのネットワークインタフェース
- AZ 毎に高可用性
- ネットワークキャパシティのシャード
- 数十マイクロ秒のレイテンシー
- AWS HyperPlane
- 水平スケーラブルなステート管理
- テラバイトのマルチテナントキャパシティ
- NLB、NAT ゲートウェイ、Amazon EFS、Transit Gateway をサポート
Transit Gateway の例
- Flat: すべての VPC は、どの VPC とも会話できる
- Isolated: 何も会話させないで、VPN 経由ですべてを送り返す
Flat: Transit Gateway ルートドメイン（ルートテーブル）
各 VPC のルートテーブルでは、すべての VPC CIDR を含む、10.0.0.0/8 が Transit Gateway に向けられ、Transit Gateway のルートテーブルでは、すべての VPC に対してルーティングされているので、すべての VPC 間 で Any-to-Any な通信が可能な状態です。
Isolated: Transit Gateway ルートドメイン
先ほどはデフォルトのルートテーブル 1 つでしたが、今度は VPC 用と VPN 用の 2 つが Transit Gateway に作成されています。VPC 用のルートテーブルには各 VPC 向けのルートが作成されていないため、VPC 間の通信は出来ません。一方、VPN ルートは記載されいるので、各 VPC から VPC を経由して オンプレミスに接続することは可能です。
簡単な比較: Transit Gateway と Transit VPC
| Transit VPC | Transit Gateway |
|---|---|
| ユーザ管理のインスタンス | AWS ネイティブなサービス |
| VPN と VGW を使用 | ENI を使用 |
| スケールと管理は難しい | 水平にスケール |
| セグメント化は難しい | 柔軟にセグメント化できる |
Transit VPC を使用する理由はありますか？
- Transit Gateway を追加することでこれらを簡単にする方法について説明
- 現在 1つを使用し、それはあなたのために動いている
- Transit Gateway に移行
- 追加の可視性とモニタリングが必要な場合
- タグ付けを使用した自動化された VPC ネットワークを使う場合
- 以下の追加サービスを使用したい場合
- セキュリティ機能
- SD-WAN
- NAT
- 独自の機能
- 現在 1つを使用し、それはあなたのために動いている
何も取り除いていない、追加しただけ
- Transit Gateway で従来のオプションをすべて使用できます
- VPC ピアリング
- AWS Direct Connect
- ELB
- AWS PrivateLink
- AWS Cloudwatch メトリクス
- AWS CloudFormation
- Transit VPC
全部詰め込んだ参考のアーキテクチャ
アカウント戦略
アカウントと VPC セグメントテーション
- 大規模な VPC またはアカウントでは、ポリシーと IAM でセグメント化
- AWS アイデンティティとアクセス管理
- 厳格なセキュリティグループとルーティング
- タグでリソースを識別する
- 小規模な VPC またはアカウントでは、インフラとネットワークでセグメント化
- インフラの自動化
- 標準の AWS Direct Connect と VPN
- 標準のサブネットとルーティング
- インフラ と ネットワーク
VPC Sharing と Resource Access Manager を使えば両方できる。
VPC Shareing and Resource Access Manager
VPC Sharing の利点
- 責任の分離
- インフラを厳密に制御（ルーティング、IPアドレス、VPC 構造）
- 開発者は自身のリソース、アカウント、セキュリティグループを所有する
- 使われていないリソースの削減
- 高密度なサブネットと、最大 5 つの CIDR 追加
- もっと VPN や AWS Direct Connect の効率的な使用
- アカウントとネットワークの分離
- 追加のインフラストラクチャなしでアカウントの保護と課金
- たくさんのアカウントといくつかのネットワーク
- VPC ピアリングの負担を回避
他のアカウントについての検討
- すべてに合わせるためにワンサイズにする必要はない
- 必要であれば、AWS Transit Gateway は大量の VPC も制御できる
- VPC Sharing は AWS Organization で機能します
- VPC Sharing はリソース利用の制限は出来ません
- NAT ゲートウェイ、VPN、サブネットアドレススペース、セキュリティグループは共有制限がある
- VPC Sharing は VPC に制限を書けれません。アカウント制限のみです。
- AWS Lambda の専用 IP スペースのような高度にスケーラブルなサービスを提供する
セグメンテーション
セグメンテーション: インプットの決定
- アカウント間、VPC 間、テナント間 の関係
- アカウントおよびテナントはお互いを信頼するか？
- 現在のネットワークセグメンテーションは意図されたものか、副作用によるものか？
- セキュリティ、ネットワークは誰の所有か？
- 相互チームか、集中管理のチームか
- コンプライアンスとガバナンスの要件は？
- スコープはアカウントもしくは、VPC レベルで減らせる
セグメンテーション: レイヤー
- アカウント内
- IAM ユーザと、IAM ロール
- セキュリティグループ
- VPC
- ルートテーブル
- ネットワーク ACLs
- VPC 分離
- セキュリティベースライン
- IAM: ユーザーとロールの間のアカウント内のアクションと権限を制御する
- セキュリティグループ: ホワイトリストポート、プロトコル、ネットワークアクセスのためのセキュリティグループ
- ネットワークセキュリティ
- ルートテーブル: ルートテーブルポリシーは、ネットワーク上でどの VPC リソースがアクセスできるかを定義します
- ネットワーク ACL: 特定のサブネット、ポート、または宛先間のアクセスを遮断
- VPC 分離: 他のテナントと完全分離
Transit Gateway に接続すると以下のようになります。
ネットワーク ACLs と Shared VPC のセグメント化
- 単一の VPC の動作を模倣する
- サブネット間のトラフィックを許可
- 他のテナントからのインバウドを拒否
Flat: Transit Gateway ルートドメイン
すべてのルートとアタッチメントは単一のルートテーブルにあります
Isolated: Transit Gateway ルートドメイン
- VPCs が共有リソースへのルートを持つルートテーブルにアタッチする
- 共有リソースは、すべてのリソースへのルートを持つルートテーブルにアタッチする
各 VPC は共有サービスにはアクセスできますが、他の VPC 間ではアクセスできません。
セグメンテーションの考慮: どこから始めるか
- セキュリティグループと IAM は効果的で実績があります
- IAM、セキュリティグループ、セキュリティ設定の監視を推奨
- Shared VPCs
- テナントは、インターネットや他のテナントからのアクセスを制限する必要がある
- VPC ピアリングを使用する VPCs は、Shared VPC の恩恵を受ける可能性がある
- リソースまわりの設計と競合の制限
- VPC の分離
- 多くの場合、最高のセキュリティ決定が最も簡単です。VPC 分離はシンプルです
- 強力なネットワークセグメンテーションとリソース分離のためには、VPC 分離を使用してください
- トランジットゲートウェイは、多くの VPC でスケーリングの問題を取り除きます
- Transit Gateway のルートテーブルはマルチ VPC ポリシーを定義
- 本番、開発環境を隔離し、共有リソースへのアクセスを許可することを検討する
共有サービス
共有サービス接続オプション
- VPC ピアリング
- 1対1 の接続
- 100 VPC までスケール
- VPC 間のセキュリティグループ
- リージョン間ピアリング
- AWS PrivateLink
- 1対多 の接続
- 高いスケーラビリティ
- CIDR の重複をサポート
- ELB を使用
- ロードバランシングと時間毎のエンドポイントコスト
- Transit VPC
- スポークとしての共有サービス
- 帯域幅の制限
- 管理は複雑
- インスタンスとライセンスのコスト
- AWS Transit Gateway
- ルートテーブルで 多対多 もしくは 1対多
- 高いスケーラビリティ
- AZ エンドポイントあたりの時間コスト
Transit Gateway を使った共有サービス
Transit Gateway と PrivateLink を使う
| 項目 | AWS PraivateLink | AWS Transit Gateway |
|---|---|---|
| スコープ | アプリケーション共有サービス | 多くの VPC でネットワーク共有サービス |
| 信頼モデル | 相互信頼はありません | VPC ごとの信頼、集中管理 |
| 依存関係 | 負荷分散とアプリケーションアーキテクチャ | Transit Gateway の集中管理 |
| スケール | 数千のスポーク VPC | 数千のスポーク VPC |
オンプレミスへの接続
- Virtual Private Gateway VPN
- VPC ごと
- トンネルあたり 1.25 Gbps
- 転送中に暗号化
- AWS Direct Connect
- VPC ごと（ポートあたり 50）
- Direct Connect Gateway を使ってマルチ VPC
- 帯域制限なし
- Amazon EC2 独自 VPN
- VPC ごと、もしくは複数（Transit VPC）
- 帯域幅はインスタンスタイプで変わる
- AWS マーケットプレイスで選択
- スケーラビリティは一般に管理の複雑さによって制限される
- AWS Tarnsit Gateway VPN
- 複数 VPC
- 必要に応じて VPN 接続を追加する
- トンネルあたり 1.25 Gbps
- ロードマップ: AWS Direct Connect
多くの VPC に AWS Direct Connect
ポートあたり最大 50 の VIF
AWS Direct Connect: Link Aggregation
LAG に最大 4 ポートで、それぞれ 50 の VIF
Direct Connect Gateway
Direct Connect Gateway あたり、最大 10 VGW
AWS Direct Connect と Transit Gateway
ネイティブな Direct Connect サポートは 2019 Q1 の予定
VPN と Transit Gateway
- Trangit Gateway（TGW）と VPN の統合
- VPN は 仮想プライベートゲートウェイ（VGW）と同様に動作する
- 帯域幅、構成、API、コスト、経験
- VPN は VGW の代わりに TGW にアタッチする
- 同じく、トンネルあたり 1.25 Gbps の帯域幅が適用される
- VPN は 仮想プライベートゲートウェイ（VGW）と同様に動作する
- 複数 VPC エッジへの暗号化
- トラフィックは VPC 内に入るまで暗号化される
- VPC 間のトラフィックをネイティブに暗号化しない
- リージョン間 VPC ピアリングは暗号化しています
VPN と Transit Gateway: 帯域幅の追加
- 複数のトンネルにまたがってトラフィックの拡張をサポート
- BGP マルチパスで ECMP（ECMP: Equal Cost Multi-path）サポート
- テストされたトラフィックの最大は 50 Gbps
- トラフィックをより小さく分割、マルチパートアップロードなど
- オンプレ構成の確認
- マルチパス BGP
- ECMP サポート、イコールパスの量、リバースパス、フォワーディング、スプーフィングを確認
- BGP のみサポート、静的ルートはサポートされない
Transit VPC 1.1
ネットワークサービス
リファレンスアーキテクチャ
サービス毎に VPC を分けることはよくある構成だったと思いますが、必ずしも必要ではありません。ルーティングとそのタイプを理解して組み合わせることが出来ます。
アウトバウンドサービス VPC
- ユースケース
- URL フィルタリング、NAT ゲートウェイ、DLP、Web プロキシ
VPN サービス の導入デザイン
水平にスケーラブルなサービスパターン。サービスが BGP、VPN、NAT をサポートしている場合に、優先のメソッドです
- インスタンスがサポートできる必要があります
- Transit Gateway への VPN
- Transit Gateway への BGP（ECMP 要件）
- インターネットへの Source NAT
- パフォーマンス
- IPsec オーバヘッド
- オートスケーリング設計との互換性
- 累積帯域幅制限はない
- 高可用性
- BGP と VPN の DPD（Dead Peer Detection）handlerによるフェイルオーバー
- フォールトトレランスに必要な API コールはない
- オプションでインスタンスを Amazon EC2 自動リカバリに配置
- ステートフルサービス
- Source NAT を使用して、同じインスタンスへのリターンフローを保証する
アウトバウドサービス VPC: インタフェース
BGP、VPN などを使わない場合のパターン。アウトバウンド VPC には、VPC アタッチメントで接続しています。各 SNAT のインタフェース毎にルートテーブルを持つことになります。
インタフェースサービスの導入デザイン
より単純なパフォーマンスパターン 単一のサービスインスタンスのパフォーマンス（最悪の場合のシナリオ）内に留まり、独自の高可用性チェックを構成します。
- インスタンスがサポートできる必要があります
- インターネットへの Source NAT
- パフォーマンス
- オーバーヘッドはありません（8500 MTU）
- AZ ごとに 1 つの Transit Gateway アタッチメントに制限されているため、ルートテーブルは 1つです。
- 可能であれば、トラフィックは同じ AZ 内で転送される
- トラフィックはインスタンス間で均等に分散されない可能性があります
- 高可用性
- VPC ルートのヘルスチェックは組み込まれておらず、監視と管理が必要です
- オプションでインスタンスを Amazon EC2 自動リカバリに配置
- ステートフルサービス
- Source NAT を使用して、同じインスタンスへのリターンフローを保証する
エッジサービス VPC: インバウンド
- ユースケース
- WAF、検査、負荷分散 などのユースケース
エッジサービス VPC: SD-WAN
- ユースケース
- SD-WAN、ルーティング、外部製品の VPN クライアント、プライベート VIF 上の AWS Direct Connect
Reminder
既存のネットワークサービスや DMZ が便利かもしれませんが、問題があるかもしれません。運用プロセス、代替案、および自動化を評価することを忘れないでください
VPC to VPC サービスの導入
- ユースケース
- 侵入検知/防止(IDS/IPS）、ファイアウォール、次世代ファイアウォール（NGFW）、統合脅威管理（UTM）
オンプレミスサービス VPC の導入
Transit Gateway ローンチパートナー
マルチリージョン
リージョン間 Transit Gateway も、今後、サポートされるようです！（Direct Connect Gateway の立ち位置は、今後どうなるんでしょうか、、）
まとめ
持ち帰ってほしいこと
- 多くの VPC に水平に拡大するツールとアーキテクチャがあります
- あなたの特定のユースケースのための余地
- 規模とセキュリティ要件を満たすためにサービスを組み合わせて使用する
アドバイス
- ネットワーキングの変更は速く、水晶玉はない。（占い師のように、将来を見通せないってことでしょうか）
- シンプルにスタート！シンプルを保つ。複雑さを軽減してより小さなスコープにする。
- セグメント化し、必要に応じて変更する
- 実験とテスト
さいごに
前回、聴講した Introduing セッションとは違って、ユースケースを交えた具体的なアーキテクチャの説明などあり参考になりました。また、これまでサービス毎に VPC 分割して、インフラ部分からネットワークを分離する構成はよくやっていたのですが、本セッションを聞いて、違ったアプローチでのネットワーク分離も取り込んでい行きたいと思います。Transit Gateway はやっぱり激アツなサービスですね！（なので、早く東京リージョン来てください。。）
以上！大阪オフィスの丸毛（@marumo1981）でした！
4
