AWS、Microsoft Azure、Google Cloud 向けのプライベート SLA を理解する

AWS、Microsoft Azure、Google Cloud 向けのプライベート SLA を理解する

確実な構築の決定を行うには、クラウド サービス プロバイダーの SLA を完全に理解する必要があります。

ビジネスの成功で鍵となるリソースにネットワーク接続を構築する際に最優先されるのは高可用性ソリューションです。クラウド構築は急速に拡大を続けることが予想されるため、CSP によって提供されるサービス水準合意 (SLA) を理解すると、構築の決定を導く上で役立ちます。

AWS (Direct Connect)、Microsoft Azure (ExpressRoute)、Google Cloud (Interconnect) の大手 CSP が SLA に対してそれぞれ異なるアプローチを取っていると、決定は容易ではありません。例えば、Microsoft では、各 ExpressRoute がプロビジョニングされる SLA をサポートする機能を提供していますが、Google および AWS では、接続を追加することで構築に SLA を組み込むオプションを提供しています。

大手 CSP 3 社がそれぞれどのように SLA に対処しているかを見ていきましょう。

Microsoft Azure ExpressRoute

Microsoft は、ExpressRoute 構築ごとに 99.5% のアップタイム SLA を提供しています。Azure は、SLA を標準オファリングの一部として提供する唯一のクラウド プロバイダーです。1 つの ExpressRoute は、プロビジョニングされた ExpressRoute ピア ロケーションで 2 つの Microsoft Enterprise Edge (MSEE) ルーターに接続する機能を提供し、顧客は冗長レイヤー 2 (イーサネット) 接続を備えた冗長デバイスに接続できます。顧客は、SLA 要件を満たすために各 MSEE で BGP ピア (レイヤー 3) を設定する必要があります。両方のピアがアクティブであり、顧客はルーティングを制御できます。顧客は、1 つのピアをプロビジョニングすることもできますが、その場合、AzureSLA の対象にはなりません。

Microsoft SLA は Microsoft ネットワークに適用され、Azure エッジ/ピア ロケーション MSEE ルーターから Microsoft ネットワーク全体へ拡張されます。顧客は、1 台の顧客デバイスで接続/ピアの両方を終端したり、2 台の顧客デバイスで接続を分岐したりすることができます。各 MSEE で両方のピアが確立される限り、Microsoft SLA が適用されます。その他の ExpressRoute SLA の詳細については、ExpressRouteSLA を参照してください。

サンプル構成:

顧客デバイスが 1 台の場合の例:

multicloud-webinar-slas-single-device-example-1

顧客デバイスが 2 台の場合の例:

multicloud-webinar-slas-customer-dual-device-example-2

Google Cloud Interconnect

Google は、自社のプライベート接続オファリング経由で複数の SLA を提供します。顧客は、99.9% または 99.99% のアップタイム SLA 構成をプロビジョニングできます。これは、Dedicated および Partner Interconnect モデルによってサポートされます。SLA は、ExpressRoute 同様、標準オファリングではデフォルトで提供されません。SLA をサポートするためには、顧客は複数の GCP Interconnect をプロビジョニングする必要があります。詳細については、Google SLA を参照してください。

Google Cloud SLA 99.9%

Google で 99.9% SLA を受け取る場合、顧客は 2 つの VLAN (Interconnect) アタッチメントをプロビジョニングする必要があります。VLAN アタッチメントは、同じメトロ エッジ アベイラビリティー ドメイン内のゾーン 1 およびゾーン 2 を介して接続する必要があります (この記事の最後に記載されたサービス定義を参照してください)。同じ VPC および GCP リージョンで構築される顧客デバイスと Google Cloud Router との間で、顧客が BGP ピアリングを設定します。

Google Cloud 99.9% SLA の例:

以下に示すのは、顧客デバイスが 1 台の場合の例です。Azure 同様、顧客はそのネットワーク上で 1 台または 2 台のデバイス構築を選択できます。SLA は GCP ネットワークに適用されます。

multicloud-webinar-slas-single-customer-device-3

Google Cloud SLA 99.99%

Google で 99.9% のアップタイム SLA を受け取る場合、Interconnect の顧客は 4 つの VLAN アタッチメントをプロビジョニングする必要があります。99.9% ソリューション同様、1 つのメトロ エッジ アベイラビリティー ドメイン内のゾーン 1 およびゾーン 2 から 1 セットの VLAN アタッチメントがプロビジョニングされます。99.99% ソリューションでは、2 つ目のメトロ エッジ アベイラビリティー ドメイン内のゾーン 1 およびゾーン 2 からさらに 2 つの VLAN アタッチメントをプロビジョニングする必要があります。Google Cloud Router も 4 つ必要で、リージョン 1 に 2 つ、2 つ目のリージョンに 2 つが構築されます。すべて同じ VPC で構築する必要があります。各リージョン内で Google Cloud Router 経由でルーティングするためには、Global Dynamic Routing を有効にする必要があります。

Google Cloud 99.9% SLA の例:

以下に示すのは、2 つのデータ センター内で顧客デバイスが 1 台の場合の例です。顧客は、そのネットワーク上で複数のデータ センターとルーティング デバイスに構築できます。SLA は GCP ネットワークに適用されます。

multicloud-webinar-slas-single-customer-device-in-two-data-centers-4

AWS Direct Connect

AWS は、Direct Connect SLA をサポートするための特別なオプション セットを提供します。AWS は、Microsoft や Google AWS とは異なり、SLA が Dedicated モデルでしかサポートされず、顧客は AWS への物理的な接続を所有します。AWS はパートナー モデル経由で SLA を提供しませんが、HA ソリューションの設定に関するガイダンスは提供されます。詳細については、「AWS Direct Connect Resiliency Recommendations (AWS Direct Connect の障害耐性に関する推奨事項)」を参照してください。

AWS SLA 99.9%

AWS Direct Connect 99.9% アップタイム SLA をサポートするには、顧客は 2 箇所以上の Direct Connect ロケーションの専用接続で仮想インターフェイスをプロビジョニングする必要があります。一方の接続は、顧客のワークロードが配置されているリージョンに関連付けられた Direct Connect ロケーションで完了しなければなりません。エンタープライズ サポート プランも契約している必要があります(注:エンタープライズ サポート プランの最低料金は、月額 $15,000 です。詳細については、「エンタープライズ サポート コスト」を参照してください。

プライベート エンドポイントの場合、ワークロードは 2 つ以上のアベイラビリティー ゾーンでプロビジョニングする必要もあります。

AWS SLA 99.99%

99.99% SLA は、すべての 99.9% SLA 要素を取り入れていますが、追加要件がいくつか加わります。具体的には、2 つの仮想インターフェイスおよび Direct Connect が追加されています。2 箇所以上の Direct Connect ロケーションが必要です。顧客が 1 箇所のロケーションで 2 つの接続を持つ場合、それぞれが固有の AWS エンドポイント (ルーター) に接続されていることを確認する必要があります。また、顧客は、AWS エンタープライズ サポートと、含まれるリソース ID (サービス クレジットの適格条件となる最小構成要件を満たす) のリストを提供するために、AWS ソリューション アーキテクトに相談する必要もあります。AWS SLA ガイダンスについては、「AWS Direct Connect Service Level Agreement (AWS Direct Connect サービス内容合意書)」を参照してください。

HA および SLA に裏付けられたプライベート CSP 接続をサポートするソリューションの構築は困難な場合があります。この過程において、Megaport のスペシャリストがお客様の案内役を務めます。当社の Software Defined Network (SDN) は、CSP が推奨する HA および SLA ソリューションをサポートするように設計されており、接続の構築に伴う複雑な作業を排除します。Megaport に関する詳細とガイダンスについては、Megaport のウェブサイトを参照してください。

サービス定義:

Google

VLAN アタッチメント: 相互接続アタッチメントとも呼ばれます。VLAN アタッチメントは、顧客のオンプレミス ネットワークとその VPC ネットワーク内の 1 つのリージョンを結ぶ論理的な接続です。

Cloud Router: Cloud Router は、Border Gateway Protocol (BGP) を使用して、顧客の VPC ネットワークとそのオンプレミス ネットワークとの間で経路を動的に交換します。VLAN アタッチメントを作成するにあたっては、接続先の VPC ネットワーク内で Cloud Router を作成するか、または既存の Cloud Router を使用する必要があります。次に、アタッチメントをその Cloud Router に関連付けます。Cloud Router が、顧客のオンプレミス (ピア) ルーターに接続する BGP セッションを作成します。

大都市圏: 大都市圏 (メトロ) は、コロケーション施設が配置されている都市です。

アベイラビリティー ドメイン: 各大都市圏には、エッジ アベイラビリティー ドメインという 2 つのゾーンが含まれます。これらのドメインは、定期メンテナンス中に分離性を提供します。つまり、同じメトロ内の 2 つのドメインがメンテナンスのために同時にダウンすることはありません。この分離性は、冗長化を構築する際に重要です。

. . .

関連記事

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

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

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

続きを読む
Firewall as a Service (FWaaS) について

Firewall as a Service (FWaaS) について

自宅を誰でも出入り自由にしている人はいないでしょうが、それはネットワークでも同じです。ここでは、Firewall as a Service (FWaaS) がクラウド インフラストラクチャそれ自体のセキュリティ ガードとして機能し、より優れたデータ保護を実現する仕組みを紹介します。 サイバー攻撃がこれまで以上に頻繁かつ高度になっている現在ほど、ネットワーク セキュリティを再考することが重要な時期はありません。クラウドの可能性に気づき、Network as a Service (NaaS) や [Software as a Service](https://azure.microsoft.com/en-gb/resources/cloud-computing-dictionary/what-is-saas/#:~:text=Software as a service (SaaS,from a cloud service provider.) (SaaS) などの「サービスとしての」ソリューションに目を向けてクラウド技術の多くの利点を活用する企業が増える中、ネットワークの保護を支援する別のクラウド ソリューションが登場しています。それは、サービスとしてのインフラストラクチャ (IaaS) であり、具体的には FWaaS (Firewall as a Service) のことです。 「サービスとしての」モデルとは、IT サービスをオンデマンドで、クラウドや Network as a Service Provider (NaaS) を通じて遠隔地から提供することを指します。このようなサービスは、本質的にクラウドネイティブであるため、設備投資がほとんど必要なく、ビジネスの変化するニーズに合わせて拡張することができます。このように、FWaaS は従来のファイアウォールとは異なり、クラウドや NaaS プロバイダーを通じて提供されるため、オンプレミスのインフラストラクチャの設置やハードウェアのメンテナンスは必要ありません。 ネットワーク ファイアウォールは建物の警備員に例えることができ、入館しようとする人物の身元を確認し、許可されていない人の入館を拒否します。ネットワークのファイアウォールも同様の役割を担っており、侵入しようとするトラフィックを検査することで、未知の脅威や不要な脅威からネットワークを保護することができます。 企業のグローバル化や遠隔地化が進む以前は、オフィス内に設置された従来のファイアウォールで十分であり、IT 部門はファイアウォールを本来の設置場所以外に拡張する必要はありませんでした。しかし今日では、ファイアウォールの境界は大きく拡張され、グローバルな労働力の需要に対応するエンドポイントや、ネットワークの境界が明確に定義されていないデバイスが至る所に存在しています。 Firewall as a Service (FWaaS) の仕組み FWaaS は、企業ネットワークとパブリック インターネットとの間に位置し、複数のフィルタリングとセキュリティ対策により、企業のアーキテクチャをサイバー攻撃から保護し、脅威がネットワークに侵入するのを防ぎます。脅威を検知した際の自動対応、完全なイベント記録、侵入防止システム (IPS)、ドメイン ネーム システム (DNS) のセキュリティなど、さまざまな対策が施されています。

続きを読む
マルチクラウド セットアップの隠れた3つのコスト

マルチクラウド セットアップの隠れた3つのコスト

ビジネスの収益を伸ばしたいと考えている場合、クラウドには徐々に積み重なる手数料がいくつかあることを認識しておく必要があります。ここではその管理方法を紹介します。 クラウドへの接続にコストがかかることは誰もが知っています。サブスクリプション料金またはストレージ パッケージであれ、クラウドの利用料金はすぐに積み重なる可能性があります。 2024 年までには 94% の組織によるマルチクラウド ネットワークの採用が予想され、COVID-19 のパンデミックによるどこでも働けるモデルへの移行により、マルチクラウドの人気は高まるばかりです。マルチクラウドは、ネットワーク パフォーマンス、セキュリティ、および管理にさまざまなメリットを提供する設定となっています。しかし、適切な設定がなければ、全く予期しない状態からコストがすぐに積み重なる可能性があります。幸い、予想外の出来事なく、安心してマルチクラウド体験をするために、これらの隠れたコストを削減および管理する方法があります。 利点 お客様のビジネスが複数のクラウド プロバイダーに接続することで、従来または単一のクラウド ネットワーク設定では保証できない、いくつかの利点が期待できます。まず、最高の機能の中から必要なものを自由に選択することができ、ベンダー ロックイン (他のベンダーへの切り替えが実用的でないため、ユーザーがサービスの利用継続を余儀なくされること)から解放されます。また、データの漏洩やシステム クラッシュが発生し、隣接するプロバイダーのサービスが突然停止した場合でも、安全でコスト効率の高い災害復旧計画を利用できます。 マルチクラウドのコツをさらに知りたいですか?こちらから 2022 年初心者向けガイドをお読みになり、お客様のビジネスにもたらされるその他のメリットをご覧ください。 隠れたコスト 適切な計画なしでは、クラウドの利便性にコストがかかる可能性があります。回避できない接続料金に加え、企業によるクラウド支出の予算を立てる際、考慮すべき重要なコストが 3 つあります。

  1. エグレス料金 – クラウド サービス プロバイダー (CSP) からのデータ移行コスト
  2. ネットワーク アンダーレイ – クラウドへの接続およびクラウド間の接続をインストールして管理するためのコスト
  3. クラウド間のデータのヘアピン現象 – 現場のデータ センターを経由するクラウド間のルーティング コスト (仮想クラウド ルーターを使用することで軽減できるコスト)。 エグレス料金 必要な量のデータを CSP に移行できる一方、データを CSP から移行するときは、データ 1 GB ごとに課金されます。そのため、エグレスとは「外に出る」ことを意味します。これらの料金は、通常後払いで請求されるため、気付かないことが多くあります。つまり、アプリケーションがデータを抽出し続ける中、見えないところで料金がかさむ場合があります。エグレス料金の監視と管理は、グローバル ワークロードのサポートをマルチクラウド プロバイダーに依存している大規模組織にとって、重要な課題となる可能性があります。 これらの料金は、移動するデータの容量や、移動先によって異なります(可用性ゾーン間でデータを転送する場合のコストは低いですが、たとえば、大陸間でデータを移動する場合、高額のクラウド利用料金を請求される恐れがあります)。さらに、これらの料金はすべて、インターネットなど、パブリック接続を介してトラフィックやデータをルーティングする際、高いレートで課金されます。 エグレス料金がビジネスの成長に予期せぬ障害となり得る一方、料金を確実に削減する方法があります。 エグレス料金を削減する方法 高額な隠れたエグレス料金を常に把握しておく方法はいくつかあります。いくつのクラウドにどれだけの容量のデータを保存するかを戦略的に整理、移行することで、CSP から請求されるエグレス料金を最小限に抑え、必要なことへより多くの予算を割り当てることができます。 まず、リスクの高いパブリック インターネット VPN とは対照的に、セキュアなプライベート ネットワーク経由で接続を確立することが重要です。この方法では、CSP から次のような利益を得られます。各プロバイダーの独自のプライベート接続 (AWS Direct Connect や Microsoft Azure ExpressRoute など) に接続することにより、クラウド移行のエグレス料金を大幅に削減することができます。

続きを読む