AzureとAWSを両方使う構成になったとき、先に詰まるのは機能の話ではありません。「この二つを、どうやって安全につなぐか」がまず壁になります。
私がこの構成を組んだときも、最初に時間を取られたのはそこでした。各クラウドの中はそれぞれ動いている。なのに、その間に経路がないから、実質ばらばらに動いているだけの状態です。繋がっていない二つのクラウドは、マルチクラウド構成とは呼べません。
AzureとAWSをつなぐとき何が要るか
両クラウドを安全につなぐには、互いの「玄関」をVPNゲートウェイで設けて、その間にIPsecトンネルを張ります。IPsecは、インターネットを経由しながら暗号化した専用経路を作る仕組みです。
仕組みとしては、こういう形になります。
Azure上のリソース
↓ Azure VPN Gateway
（AzureとAWSの間の暗号化トンネル）
↓ AWS VPN Gateway / Customer Gateway
AWS上のリソース
絵にすると単純に見えますが、この経路を実際に通すには、両クラウドで設定を合わせる作業が要ります。片方だけ設定しても接続は確立しません。
詰まりやすい場所
経路を設けることより、「設定を合わせること」のほうが手間です。
私がAIに頼んだ指示を再現するとこういう感じです。
AzureとAWSを、VPNで安全につなぎたい。
- AzureとAWSそれぞれにVPNの出入口を作って、その間に暗号化した経路を張って
- 接続が確立したあと、Azure側のリソースがAWS側のリソースにアクセスできる、その逆もできる状態にして
- 接続元のIPの範囲は、最初は必要な分だけに絞って。あとから広げられるようにしておいて
- 設定が終わったら、両側から疎通できるかを確認する手順も出して
ポイントは、「どのサービスを使え」という指示を出していないことです。何をしたいか、できあがりの状態がどうなっていればいいかを、業務の言葉で渡す。それだけで、具体的な構成の案は返ってきます。
セキュリティは後回しにしない
VPNが繋がった、で終わりにすると後で困ります。
経路ができると「通信が通る」は達成されますが、「何が通っていいか」は別の話です。接続を確立した直後は、設定次第で想定外の通信が通ってしまうこともあります。
私が先に決めたのは、許可する通信の範囲をできるだけ絞っておくことでした。最初は必要最小限だけ通して、動作確認してから少しずつ広げる。後から締めるより、最初から絞って通す方が事故が少ない。
経路を自前で持つ意味
マネージドのサービス間連携（各クラウドのAPIを別々に叩く形）でもやれないことはないですが、データや処理がクラウドをまたぐ構成では、経路が安定して存在していることがそのまま信頼性になります。
サービスを分けた理由がある。コストの都合でもあるし、機能の都合でもあります。そこに「繋ぐ経路をどこかのサービスに任せている」状態より、「自分で持って自分で管理できる」ほうが、構成全体を把握しやすい。
どちらがいいかは状況によりますが、私はこの構成では自前を選びました。管理の手間は増えますが、何かあったときに手が届くからです。