AzureとAWSを直結する前に、プレビューの1Gbps制限を確認

AzureとAWSをプライベート接続するには、Azure Multicloud InterconnectとAWS Interconnect - multicloudを組み合わせる。Azure側ではExpressRoute上の専用経路を使い、AWS側ではDirect Connect gatewayを接続点として、パブリックインターネットを経由しないクラウド間接続を構成する。

ただし、AWS–Azure連携はプレビュー段階にあり、帯域は1Gbpsに限定される。AWSのプレビュー向け作成条件 では、顧客ごと・対応リージョンごとに1接続までとされ、一般提供の準備時にはプレビュー接続が削除される。検証用の一時構成として、代替経路と廃止手順を含めて設計する必要がある。

1. 対応リージョンと帯域要件を先に照合する

最初に、AWSの接続元リージョンとAzureの接続先リージョンが対応する組み合わせか確認する。Azure Multicloud Interconnectの接続仕様 によると、Azure側のプライベート接続はExpressRoute上に配置され、プレビュー中に接続できるのはローカルリージョンの仮想ネットワークゲートウェイに限られる。クロスリージョン接続はサポートされない。

したがって、別リージョンにあるVNetのゲートウェイを直接の接続先にする構成は採用できない。AWS側のリージョン選択とAzure側のゲートウェイ配置を個別に決めず、対応する一組として確定させる。

帯域要件も作成前に判定する。1Gbpsは接続に設定できる容量であり、アプリケーションごとの性能保証ではない。平常時またはピーク時の必要量が上限に近い場合は、検証対象の通信を限定するか、別経路へ退避できる設計を用意する。

• AWSの接続元リージョンとAzureの接続先リージョン
• 接続対象のVPC、VNet、IPプレフィックス
• VPCとVNetのアドレス重複の有無
• 平常時とピーク時に必要な帯域
• プレビュー接続を停止したときの代替経路

2. 双方のゲートウェイと経路を準備する

AWS側ではDirect Connect gatewayがInterconnectのアタッチ先になる。VPCまでの接続方式として、Virtual Private Gateway、Transit Gateway、Cloud WANのいずれを使うかを決め、既存のDirect Connect gatewayを流用する場合は関連付け済みのネットワークと経路を確認する。

Virtual Private GatewayとTransit Gatewayはリージョナルなサービスであり、接続元リージョンに対応するローカルInterconnectを使用する。AWS内の遠隔リージョンへ到達させる構成ではCloud WANを利用できるが、Azure側のローカルリージョン制限が解除されるわけではない。

Azure側では、対象VNetのローカルリージョンに仮想ネットワークゲートウェイを配置する。既存ゲートウェイを使う場合は、ExpressRoute接続への対応、既存接続への影響、経路数や処理容量を確認する。AWS側と重複しないVNetアドレス空間も必要になる。

クラウド間接続が作成されても、ルートとセキュリティ規則は自動的にアプリケーション通信を保証しない。AWSとAzureの経路表、Network Security Group、AWSセキュリティグループ、ネットワークACL、ホスト側ファイアウォールで、相手側プレフィックスと試験対象ポートを許可する。

3. AWSで要求を作成し、Azure側で承認する

作成はAWS Direct ConnectコンソールのAWS Interconnect画面から始められる。要求が受理されるとActivation keyが発行され、そのキーを相手クラウド側の承認フローで使う。承認が完了すると、Interconnectは指定したDirect Connect gatewayへアタッチされる。

1. AWS Direct ConnectコンソールでAWS Interconnectを開き、「Create new multicloud Interconnect」を選ぶ。
2. 接続先のカードからMicrosoft Azureを選び、Previewタグが付いていることを確認する。
3. AWSの接続元リージョンとAzureの接続先リージョンを指定する。
4. 接続名、1Gbpsの帯域、既存または新規のDirect Connect gateway、Azure側の所有者識別に必要な情報を入力する。
5. 設定を確認して要求を送信し、表示されたActivation keyを記録する。
6. Azure側のプレビュー用フローでActivation keyを入力し、要求を承認する。
7. Azure側の有効化とDirect Connect gatewayへのアタッチが完了するまで、双方の状態を確認する。

プレビュー対象の接続では、Activation処理にCLIが必要になる場合がある。実際に利用できる操作方法と入力項目は、接続作成時にAzure側へ提示される案内を優先する。

Activation keyは、新しい接続要求を双方で承認するためのトークンである。チャットの公開チャンネルや構成図へ記載せず、閲覧者を限定できる方法で受け渡し、承認後は不要な複製を残さない。

AWS側のInterconnect接続はプレビュー期間中無料だが、これを構成全体が無課金という意味には解釈できない。双方のゲートウェイ、クラウド内のネットワークサービス、監視、バックアップ経路については、利用するサービスごとに料金を確認する。

4. 接続状態、経路、実通信の順に確認する

疎通確認は、接続オブジェクトから実際のアプリケーション通信へ段階的に進める。最初にプロビジョニングが完了していることを確認し、次にゲートウェイの関連付け、経路、セキュリティ制御を調べる。

1. AWSとAzureの接続識別子、状態、リージョンを記録する。
2. Interconnectが指定したDirect Connect gatewayへアタッチされていることを確認する。
3. Direct Connect gatewayと、Virtual Private Gateway、Transit Gateway、またはCloud WANとの関連付けを確認する。
4. AWSの経路表でAzure側プレフィックスを、Azureの有効なルートでAWS側プレフィックスを確認する。
5. 双方のセキュリティ規則とホスト側ファイアウォールで試験通信を許可する。
6. 許可済みのTCPポートなど、実際の用途に近い通信を双方向で試す。
7. 小さな転送から負荷を上げ、遅延、パケット損失、スループットを記録する。

ICMPを許可していない環境では、pingの失敗だけでInterconnectの障害とは判断できない。一方、単一のTCP接続が成功しても、戻り経路、DNS、MTU、長時間通信が正常とは限らない。業務に近い通信条件を使い、1Gbpsの上限に対して必要な余裕があるかを確認する。

5. 接続数、冗長化、プレビュー終了後を計画する

プレビュー固有の「顧客ごと・対応リージョンごとに1接続」という条件と、AWS Interconnect全体のサービスクォータは別に管理する。AWS Interconnectの既定クォータ は、作成済みConnectionがアカウント当たり10、requested状態が4、multicloud Connectionがプロバイダーごと・アカウント当たり2である。全体クォータに空きがあっても、同じ対応リージョンへプレビュー接続を追加できるとは限らない。

AWS Interconnectの基盤に冗長性があっても、単一の論理接続が削除される場合の代替経路にはならない。通信継続が必要なら、サイト間VPNなどの退避経路を用意し、ルートの優先順位、切り替え条件、利用可能な帯域を事前に検証する。

一般提供の準備が始まると、プレビューの1Gbps接続はアカウントから削除され、その準備期間中は同じクラウドサービスプロバイダーへのInterconnectを新規作成できない。単なる帯域変更として扱わず、代替経路への切り替え、プレビュー接続に向けたルートと監視の解除、一般提供版の新規作成、不要になった関連設定の削除までを廃止計画に含める。

停止を許容できない通信をプレビュー接続だけに依存させるのは避ける。代替経路への切り替えと復旧手順を確認できて初めて、検証環境から利用範囲を広げられる。