AWS Direct Connect および Transit Gateway のエンタープライズ ガイド

AWS Direct Connect および Transit Gateway のエンタープライズ ガイド

AWS のネットワーク機能の理解が深まるように、Direct Connect および Transit Gateway について説明します。

AWS Virtual Private Cloud (VPC) ピアリング オプションはどのように進化してきたか

AWS Direct Connect が 2012 年に発表されて以来、企業は自社のクラウド サービスに専用接続を採用してきました。これにより、AWS 接続時のデータ転送量の増加、ネットワーク パフォーマンスの向上、データ プライバシーの保護が可能になりました。数々の新機能や拡張機能の導入により、AWS とのピアリングの選択肢は確実に進化しています。ここでは、その発展の軌跡と利用可能な機能の活用方法を見ていきましょう。

AWS Direct Connect のリリース

Direct Connect がリリースされた 2012 年に遡ると、Megaport を利用してレイヤー 2 経由で AWS に接続するには、AWS 側で仮想インターフェイス (VIF) に接続する VXC が必要でした。レイヤー 3 では、L2 コンポーネントを、仮想プライベート ゲートウェイ (VGW) の確立に必要な L3 コンストラクトに接続する必要がありました。VGW は、各 VPC を介して VXC を接続した AWS 上のルーティング ターゲットです。各 AWS VPC および Megaport VXC では、個別の Border Gateway Protocol (BGP) セッションおよび各 VGW への VXC/VIF を含む 1:1 のマッピングが必要でした。

Direct Connect ゲートウェイの導入

2017 年、AWS は Direct Connect ゲートウェイ (DXGW) をリリースしました。DXGW を利用すると、1 つの AWS アカウント内で最大 10 の異なる VPC に対して 1 つの BGP セッションを確立することができました。時間が経つにつれサービスが成熟し、1 つの AWS リージョンで 1 つのアカウントで 10 の VPC を利用していたものが、その後、AWS リージョン間の接続をサポートするように拡張され、最近では、複数のリージョンと複数の AWS アカウントまで拡張されました。DXGW は、1 つの標準 AWS AS 番号 (ほとんどのリージョンで 7224) からプライベート AS 番号の範囲 (64512 ~ 65534) 内の顧客定義 AS 番号 へ移行する契機になりました。VGW および DXGW は、プライベート VIF ピアリングのある顧客向けの選択肢として今でも存続しています。

(複数のアカウント/リージョンにまたがる場合も含め) AWS 内で VPC をピアリングすることは可能でしたが、DXGW を使用した場合、VIF からピアリングできるのは、隣接してピアリングされていなかった VPC 間ではなく、「次に直接接続された」VPC に対してのみでした。

Direct-Connect-Gateway

この図では、VPC「A」は (VGW または DXGW 経由で) VXC/VIF に直接リンクされ、VPC「B」および「C」は VPC「A」にピアリングされていますが、VIF と直接通信することはできないと想定します。これは推移的ルーティングとして知られています。一部の顧客は、この制約を回避するために、VPC A で仮想アプライアンス (ルーター) を実行していましたが (非公式に「Transit VPC」として知られる)、全体的な設計にはいくつかの複雑な問題がありました。

Transit Gateway:トポロジーと概要

Transit-Gateway-Topology

2018 年の末に、AWS は Transit Gateway (TGW) をリリースしました。TGW を利用すると、VPC と (推移的ルーティングの制限がある) VPC ピアリングに依存していない VPN 終端との間で経路の「フル メッシュ」の経路を渡し、複数のアカウントにまたがる数千の VPC (最大 5000) とオンプレミス ネットワークを 1 つのゲートウェイに統合する機能を提供できました。

当初、TGW では、AWS が提供する IPSEC VPN サービスを介して、関連する VPC に接続するためにのみ顧客がアクセスできました。リリース時に発表された対応リージョンは、アメリカ東部 (バージニア州)、アメリカ東部 (オハイオ州)、アメリカ西部 (オレゴン州)、アメリカ西部 (北カリフォルニア)、EU (アイルランド)、アジア太平洋地域 (ムンバイ) でした。現在では、AWS GovCloud (アメリカ西部)、カナダ (中央)、南米 (サンパウロ)、アフリカ (ケープタウン)、EU (ストックホルム)、EU (ロンドン)、EU (フランクフルト)、EU (パリ)、EU (ミラノ)、中東 (バーレーン)、アジア太平洋地域 (香港)、アジア太平洋地域 (東京)、アジア太平洋地域 (シンガポール)、アジア太平洋地域 (ソウル)、アジア太平洋地域 (シドニー)、アジア太平洋地域 (北京)、アジア太平洋地域 (寧夏) リージョンもさらに追加されました。これは、2020 年 8 月現在の状況です。

Transit Gateway for Direct Connect

Transit Gateway for Direct Connect サポートは、2019 年 4月 30 日に発表されました。 Direct Connect を利用して顧客が使用可能なモデルには、専用接続とホスト型接続の 2 種類があり、Direct Connect 経由で TGW に 接続するために 1、2、5、10Gbps の接続をサポートしています。

Megaport 経由で Transit Gateway に接続する

Direct Connect 経由の TGW がリリースされたとき、Megaport などのネットワーク パートナーは、専用接続、50 ~ 500Mbps のホスト型接続、ホスト型仮想インターフェイス (VIF) などのモデルを介して顧客を AWS に接続していました。Megaport はホスト型 VIF モデルを介して AWS を使用し、今でもサポートを続けています。ホスト型 VIF を使うことで、Megaport は、1Mbps 刻みで 5Gbps までの VXC の帯域幅のスケーリングを含め、AWS 接続時に柔軟性と拡張性を顧客に提供できます。これまで、ホスト型接続を提供するパートナーは、VIF ごとに最大 500Mbps に制限されていました。

2019 年 3 月 19 日に AWS は、ホスト型接続モデルを使用する Direct Connect パートナーの容量を増やすことを発表しました。 500Mb を超える高帯域幅オプションを含め、1、2、5、10Gbps の高速オプションもサポートします。Megaport が、ホスト型 VIF ソリューションを構築する機能を今でも顧客に提供し、プライベート/パブリック VIF をサポートする一方で、顧客には、同じ Megaport Portal を経由して 50Mbps ~ 500Mbps のホスト型接続や、Transit Gateway をサポートするために必要なより高い階層での 1、2、5、10Gbps の接続を実装する柔軟性がもたらされます。現在、Megaport には、世界中でホスト型接続に対応する 20 を超えるオンランプ ロケーションがあり、データ センターから地理的に分散した回線を使って低レイテンシーで AWS ネットワークに接続するための豊富なオプションを提供しています。

考慮すべき要因

Megaport の AWS Direct Connect パートナー モデルについて、ホスト型 VIF とホスト型接続を比較して選択する際には、いくつか考慮すべき要因があります。

  • ホスト型 VIF モデルを経由したプライベート VIF は、Direct Connect 経由の Transit Gateway をネイティブにサポートしていません。
  • ホスト型接続は、AWS と Megaport の間で 1:1 のサブスクリプションによる専用容量を提供します。 AWS では、このモデルを本番ワークロードや重要なワークロード向けに推奨しています。
  • TGW サポートは、最小 1Gbps のサービスをサポートするホスト型接続プロバイダーに依存します。トランジット VIF を作成するには、顧客が 1Gbps 以上のホスト型接続をプロビジョニングする必要があります。 低階層のホスト型接続 (50Mbps ~ 500Mbps) は、Transit Gateway をサポートするために必要なトランジット VIF の作成をサポートしていません。
  • 1 つのホスト型接続を構築する顧客は、ホスト型接続ごとに 1 つの VIF を作成できます。 50Mbps ~ 500Mbps 経由では、1 つのプライベートまたは 1 つのパブリック VIF を作成できます。1Gbps ~ 10Gbps のホスト型接続を選択すると、1 つのプライベート、パブリック、トランジット VIF を作成できます。

Direct Connect で 1Gbps 未満の要件を持つ顧客の選択肢

1Gbps 未満の Direct Connect 経由で TGW にアクセスしたい場合は、 Megaport VXC サービス全体で (すべてのリージョンで) パブリック VIF (ホスト型 VIF またはホスト型接続) を使用できます。パブリック VIF 経由の AWS IPSEC VPN サービスでは、顧客が独自のパブリック IP スペースを使用してパブリック ピアリングを実行する必要があります。または、Megaport Cloud Router (MCR) を使用して、パブリック ピアリング IP および NAT を RFC1918/プライベート IP スペースを使用する VXC 全体で提供することもできます。トラフィックは、エンドツーエンドで暗号化され、最大スループット 1.25Gbps (AWS VPN の制限) も適用されます。この AWS Sub 1G TGW Public VIF 構成に関する AWS からの追加情報については、こちらをご覧ください。

最新情報をご確認ください。当社では、AWS ネットワーク オンランプへの追加オプションを提供できるように AWS ホスト型接続ロケーションの拡張を続けています。低レイテンシーと戦略的な地理的近接性を備えたクラウドでワークロードにアクセスするための最適なパスを Megaport エンタープライズ顧客に提供します。

AWS Transit Gateway: その内容と仕組み

ホスト型接続:新しい速度とサポートの告知

寄稿者:

Matt Simpson、Megaport クラウド担当副社長
Jason Bordujenko、Megaport アジア太平洋地域ソリューション責任者
Mike Rockwell、Megaport ソリューション責任者

:これは、2019 年 6 月 12 日に公開された記事の更新版です。

 

タグ:

関連記事

簡単にクラウド ネットワークを最新化する 3 つの方法

簡単にクラウド ネットワークを最新化する 3 つの方法

クラウド ネットワークの分散化が進む中、ビジネスとともに成長するダイナミックなネットワークが必要不可欠になっています。ここでは、その達成方法を紹介します。 この数年間、私たちの誰もが仕事のやり方や場所について再考を迫られました。分散したリモートの労働力を活用できる機能のあるクラウドのおかげで、今でも多くの企業が操業を続けていますが、クラウドがなければ、パンデミックを乗り切ることができなかった可能性もあります。しかし同時に、このオンプレミスからの急激なシフトは、絶えず変更とアップグレードを必要とする状況を作り出しています。 これを行うには次の 2 つの方法があります。必要に応じて段階的な変更を行う。これには常に修正と設備投資が伴う。または、ネットワークの柔軟性を高めることで、管理しやすいコストで、ニーズの変化に対応し、経時変化するビジネスととともに成長できるようにする。 後者の選択肢が望ましいことは言うまでもありません。しかし、この柔軟性をネットワークに織り込むにはどうすればよいのでしょうか。このブログでは、セキュリティ、パフォーマンス、コスト管理を向上させるために、現在のクラウド ネットワークを最新化し、最小限のメンテナンスで将来にわたってビジネスとともに成長するための 3 つの簡単な方法を紹介します。 1.プライベート接続のみの使用 クラウドへの接続やクラウド間の接続を迫られると、ついパブリック インターネットを使いたくなってしまうことがあります。それが最も手っ取り早い方法だからです。短期的にはそうかもしれませんが、大きなデメリットも考慮する必要があります。 信頼性の低さ 高性能ネットワークは高可用性に依存しますが、これはパブリック インターネットでは提供されません。パブリック パスのトラフィック変動は、特に需要のピーク時にボトルネックとなり、応答時間の低下や予測不可能なレイテンシを引き起こす可能性があります。その結果、生産性や利益に影響を与える可能性があります。 CSP 接続にパブリック インターネットを使用することは、ネットワークの制御を放棄することを意味し、接続の速度と一貫性がこれらのトラフィックの変動や停止に左右されることになります。 コストの増加 企業では、既に多くの業務でパブリック インターネットを利用している可能性が高いため、その既存の接続を利用してクラウド サービス プロバイダー (CSP) にアクセスすることが最もコスト効率の良い方法と思われるかもしれません。しかし、この接続方法は見掛け倒しです。 インターネットを接続手段として使用する場合、CSP がほとんどの場合、高いエグレス料金を課すだけでなく、接続の信頼性が低いと、ビジネスに大きな損失をもたらすことになります。さらに、必要な帯域幅に合わせて接続を拡張する機能がないため、最大帯域幅のシナリオをプロビジョニングして料金を支払う必要があります。 セキュリティの脆弱性 従来、パブリック インターネットに接続することは「データを目的地に送信する前に鍵をかけない金庫に入れる」ようなものだと言われてきました。インターネットのような共有パスを通過するデータは、サイバー攻撃に対してはるかに脆弱です。さらに、目的地に到達するために多くの自律システム (AS) パスを通る必要があるため、長時間これらの脅威にさらされることになります。 クラウドネット ワークの最適化について言うと、最適な方法はプライベート接続であり、これを行う最も簡単な方法は Network as a Service (NaaS) です。この仮想プライベート ネットワーク層が、インターネット サービス プロバイダー (ISP) に関連する高いコスト、セキュリティ リスク、信頼性の低いパフォーマンスを回避するだけでなく、適切な NaaS プロバイダーは、成長するビジネスのパフォーマンスを確保するために必要な接続を経時的に拡張できるようにします。 NaaS で強化されたネットワークでは、需要の急増に影響されることなく、より信頼性の高い一貫性のある体験を享受できます。そして最も重要なのは、プライベート接続では、ネットワークの可視性を高めることでコストを抑制し、CSP による割引が適用されるため、エグレス料金を低く抑えることができる点です。 Megaport の NaaS が、拡張可能で高性能なプライベート接続を実現する仕組みをご覧ください。 2.クラウド スタックの統合 クラウドの最新化は、単に適切な接続方法を使用するだけではありません。設定が統合されていないと、プライベート接続によって提供されるパフォーマンスの利点が限られてしまいます。クラウド スタックを統合し、ネットワーク上のすべてのクラウド プロバイダーやサービスを監視できるようにすることは、ネットワークのパフォーマンスを向上させ、長期的な成長を容易にするために重要なステップです。 クラウド スタックの統合の詳細については、こちらをご覧ください。

続きを読む
ゼロ トラスト ネットワーク アーキテクチャを採用すべきか?

ゼロ トラスト ネットワーク アーキテクチャを採用すべきか?

ゼロトラスト ネットワーク アクセスとは何か、その仕組みはどうなっているかを考察しながら、貴社がゼロ トラスト アーキテクチャを採用すべきかどうかついて見ていきます。 組織がリモート ワークをサポートするプロセスやモデルへと移行する際は、セキュリティを最優先事項とすべきです。そこで登場するのが、安全が確認されるまですべてのユーザーを潜在的な脅威と見なす「ゼロ トラスト」アプローチです。ゼロ トラスト ネットワーク アクセス (ZTNA) は、このトレンドの中核を担う機能です。 Gartner® は次のように述べています。「2024 年末までに、企業の 10% が、自社所有のキャンパス LAN でネットワーク アクセス制御 (NAC) や組み込み型スイッチング セキュリティ機能を ZTNA に切り替えることが予想される。これは 2021 年のほぼゼロ パーセントからの増加となる。」1 Gartner® による 2022 年予測の詳細については、当社のブログ記事をご覧ください。 クラウド業界において急速に大きな話題となっているのがゼロトラストです。ZTNA を使いこなしたいという場合は、以下で ZTNA の仕組みと、ゼロ トラスト アーキテクチャの採用を検討すべきかどうかについてご覧ください。 ZTNA とは? ゼロ トラスト ネットワーク アクセス (ZTNA) とは、企業のアプリケーションの周りに、アイデンティティやコンテキストに基づいた論理的なアクセス境界を作成するプロダクトまたはサービスです。簡単に言えば、すべてのエンドポイントを敵対的なものとして取り扱うネットワーク設定です。この設定は、アプリケーションが検知されないように保護し、アクセスを許可された限定的なエンティティ (通常は組織のリモート従業員) に制限するものです。 トラスト ブローカーがこれらの制限を制御し、アクセスが許可される前に各エンティティのアイデンティティ、コンテキスト、ポリシー遵守状況を確認します。さらに、これらのエンティティは、サイバー脅威に対するネットワークの露出を最小限に抑えるために、セッション中に許可されたアプリケーションからネットワーク内の別の場所に移動することを禁止されています。 ZTNA を実現するために、企業のネットワークチームは、ほとんどのネットワーク スイッチングや管理機能セットで見られるフィルタリング、プロファイリング、エンドツーエンド セグメンテーションなどのセキュリティ機能を組み込まずに企業ネットワークを編成します。その代わりに、こうした機能をクラウド サービスに置き換え、そこからアプリケーション認証と承認のリクエストをパブリック クラウドの Points of Presence (PoP) に送信します。つまり、セキュリティ管理プロセスがクラウドに移管されるということです。ZTNA がネットワークに与える負荷の増大によって生じる、アプリの可用性、帯域幅、パフォーマンスの低下の可能性を軽減する役割は、ローカル ゲートウェイが担います。 企業のネットワークに ZTNA アプローチを採用することは、アダプティブ トラスト モデルと呼ばれる、条件付きではくケースごとに信頼性が付与されるモデルにつながります。このアプローチにより、特にハイブリッド型やリモートワーク型の職場では、サイバー攻撃の可能性が大幅に低減されます。

続きを読む
IaaS 向けのクラウドホスト型 SD-WAN の隠れたコスト

IaaS 向けのクラウドホスト型 SD-WAN の隠れたコスト

SD-WAN が普及した業界では、ブランチ ロケーションをクラウドに接続する一般的な方法が 3 つあります。ここでは、それぞれの利点と限界について詳しく説明します。

続きを読む