0. はじめに
AWSにオンプレミスから接続する際、回線のセキュリティや安定性確保のためDirect Connect接続を選ぶ場合がありますが、Direct Connect接続といってもパートナーサービス利用を含めた様々なパターンがあり、費用を比較してどの構成を採用するか検討するのがなかなか大変です。
今回は、Direct Connect接続の費用見積もりにあたって比較検討するポイントを整理します。
目次
0. はじめに
1. 検討のステップ
2. 冗長化構成
3. 見積もり取得
4. 見積もりの比較
5. まとめ
1. 検討のステップ
検討にあたっては以下のようなステップが必要と考えます。
- システムの性能要件からDirect Connectを経由する通信量や必要な通信帯域を見積もる
- システムの可用性要件から採用し得る冗長化構成を決める
- オンプレ機器を配置するデータセンタやDirect Connect接続を提供する回線サービス等の各サービスの見積もりを複数取得し、比較する
- 取得した見積もりとAWS費用見積もりをあわせて検討中の構成の比較を行う
1はシステムの要件次第なので2以降について考えてみます。
2. 冗長化構成
2-1. オンプレミスからDirect Connectの冗長化パターン
可用性要件からオンプレミスからシステムの機能提供に関わるAWSリソースまでの冗長化構成を検討します。Direct ConnectについてAWSのSLA定義は以下になります。No.2は定義されておらずSLA適用外になります。SLAを満たせなかった場合、月間稼働時間に応じてサービスクレジットが返金される規定になっています。実際の障害以外にもAWSのメンテナンスによって特定のエンドポイント機器のDirect Connectが一時的に不通になる場合もあります。
| No | Direct Connectロケーション | ネットワーク機器 | コスト | SLA |
|---|---|---|---|---|
| 1 | シングル | シングル | 低 | 95% |
| 2 | シングル | 冗長化 | 中 | 規定なし |
| 3 | マルチサイト | シングル | 中 | 99.9% |
| 4 | マルチサイト | 冗長化 | 高 | 99.99% |
※Direct Connect以外の箇所はAWSのSLA規定とは別に検討する必要があります。オンプレミス拠点や閉域網の接続イメージは一例です。
東京リージョンにDirect Connectロケーションが1つかなかった時期はNo.3の構成が取れないためNo.2の構成が推奨されていましたが、現在はロケーション障害への対策としてNo.3が推奨されています。
災害対策のためシステムを東京と大阪のマルチリージョンで構成する場合は東京近郊の1ロケーションと大阪の1ロケーション(現在Equinix OS1のみ)でマルチサイト化する場合が多いと思います。
SLA適用外ですがインターネット経由のサイト間VPNやClient VPNをバックアップ回線とする構成も取り得ます。2021年9月2日に発生した大規模障害ではDirect Connectロケーションから東京リージョンの経路途中で障害が発生し、回避策としてサイト間VPNが推奨されました。非常時に素早く構築して接続を切り替えられるよう設計しておけば費用を抑えつつ耐障害性が高いシステムになると思います。
2-2. Direct ConnectからAWSリソースの冗長化パターン
Direct ConnectからAWSリソースへの接続構成によってDirect Connectで使用するVIFが変わるため、接続構成をある程度決める必要があります。VIFはDirect Connect上の論理インタフェースであり、どのVIFをいくつ使用するかで費用にも影響します。
Public VIFはDirect ConnectロケーションのルータとAWS EndpointにパブリックIPアドレスを付与して接続するためPublic IPアドレスを持つAWSサービスに接続できます。そのようなサービスにインターネットよりもセキュリティや帯域、安定性が高い回線で接続が必要な場合に使用されます。
プライベートIPアドレスでVPCに接続する際、Transit Gateway(TGW)を経由する場合はTransit VIFを使用する必要があり、そうでなくVirtual Private Gateway(VGW)に接続する場合はPrivate VIFを使用できます。Transit VIFは対応するパートナーサービスが比較的少ないためTGWの経由要否を検討した上で見積もりを取得したほうが良いです。(サービスがあっても100Mbpsまでという場合もあります)
図のようにDirect Connectの経路とは別に、Transit GatewayでVPC間を接続することもできるため、以下のメリット/デメリットから選択するのが良いと考えます。
※DXGW=Direct Connect Gateway
| No | パターン | メリット | デメリット |
|---|---|---|---|
| 1 | VGW | ・VGWで折り返してオンプレ間の通信が可能 | ・1VIFで1VPCだけに接続 |
| 2 | DXGW+VGW | ・20VPCまで接続可能 ・複数リージョンに接続可能 |
・DXGWで折り返す通信は不可 |
| 3 | DXGW+TGW | ・5000アタッチメントまでVPC等に接続可能 ・TGWで折り返す通信が可能 ・Direct Connect経由のサイト間VPNをプライベートIPで構成可能 |
・TGWの処理量やアタッチメント数による費用がかかる ・Transit VIFが必要でパートナーサービスの選択肢が減る |
3. 見積もり取得
必要な回線性能や冗長化パターン絞り込んだ上で各サービスベンダに見積もりを取得することになります。この際には以下の観点で複数パターンや複数ベンダを検討し見積もりを取得すると良いと思います。
※DXロケーション=Direct Connectロケーション
| 見積もり箇所 | 検討観点 |
|---|---|
| オンプレミス拠点 | ・ユーザ拠点を接続する必要があるなどシステムの各種制約がある場合は最優先 ・AWS Direct Connect デリバリーパートナーのコロケーションサービスを利用すればDirect Connect接続サービスと合わせてコストが低くなる傾向がある ・必要なラック数、電源容量(100V電源/200V電源)、引き込む外部回線数に応じて費用がかかる |
| オンプレミス側アクセス回線と閉域網 | ・回線インフラの冗長性確保のためインフラをNTTが提供するNTT系回線とKDDIや電力会社等が提供する回線で分けて冗長化が必要な場合はそれぞれ見積もる ・必要な回線帯域で見積もる ・ベストエフォートか帯域確保かで10倍以上費用差が出る場合があるため可用性・性能要件を元に検討する |
| 閉域網～DXロケーション | ・AWS Direct Connect デリバリーパートナーによって同じ名称でもサービス内容や制限が異なる場合があるため必要なVIF数、帯域、冗長性を明確に伝えて見積もる ・自前でルータを用意して専用接続で構成する場合はルータの調達や設計・構築・試験・運用費用も考慮する ・LAGやMacSecといった機能を使いたい場合は制約があるので要件として伝えて見積もる ※LAGのメンバポートは同一のAWS Direct Connect デバイスに収容されている必要があり、MacSecは10Gbpsおよび100Gbpsの専用Direct Connect接続でサポートされる |
4. 見積もりの比較
各サービスベンダから取得した見積もりを、構成パターンごとに足してシステムの開発・運用期間中の合計金額を見積もり、可用性や制約等との兼ね合いから最終的な構成を選択します。ベンダによっては最低利用期間を設定したり、毎年3%値上げとしている場合もあるため、それらも加味して計算が必要になります。
AWSリソースの費用はAWS Pricing Calculatorなどで見積もると良いと思いますが、DirectConnectについては以下に気をつける必要があります。
- AWS側のポートが提供されている時間に対してかかるポート時間は専用接続(Dedicated)かホスト型接続(Hosted)かによって少し単価が異なるためデリバリーパートナーがどちらを提供しているか確認する(パートナーによって『共有型、専有型』の定義が異なる)
- ポート時間はポート数分の費用がかかるため例えばLAGにより1Gbpsを2本使って2Gbpsにする場合は2倍、さらにそれを冗長化して4本使用する場合は4倍して見積もる
5. まとめ
Direct Connect接続の見積もりにあたって検討が必要なポイントを整理しました。一度構築すると変更が難しい部分になるため、十分に検討していただければと思います。
本記事の作成にあたっては以下AWS Black Beltの資料を参考にしています。
※ 本ブログに記載した内容は個人の見解であり、所属する会社、組織とは関係ありません。