思いつくネタはネットワークなんだよなあ。
(2025.06.05) VCNアタッチメントを使った接続のところにいくつか追記
(2025.06.12) FastConnectを使った接続に追記
ここで書きたいこと
VCNを繋ぐ方法としては、ローカル・ピアリングと、リモート・ピアリングがあります。
SpeakerDeckの資料を見てもそう書いてあります。
相互接続、という意味ではたぶんこの二つで正解だと思いますが、VCNを繋ぐという観点ではほかにもあるよね！？という想いから、いろいろと書き連ねてみました。間違ってたこと書いてたらスミマセン。
ここに2つのVCNがあるじゃろ？
こうやって繋ぐんじゃ。
ローカル・ピアリング・ゲートウェイを使った接続
同一リージョン内の接続の場合のみ使える接続方式。
IPv4のCIDRが重複していると接続できません。接続に失敗します。この場合は、別の方式で繋ぐ必要があります。
異なるテナント間での接続の場合は、IAMの設定が必要です。
このIAMの設定、Oracle Cloud Infrastructure 202x Networking Professionalを取ろうと思っている人は覚えましょう。試験に出ます。
ローカル・ピアリング・ゲートウェイは、VCNごとに作成上限があります。参考→ネットワーキングの制限のゲートウェイの制限
なので、ローカル・ピアリング・ゲートウェイを使ったハブ＆スポーク構成を取る場合は、上限に注意しましょう。
また、ローカル・ピアリング・ゲートウェイに、他のローカル・ピアリング・ゲートウェイを宛先にしたルート表は関連付けられません（関連付けようとしても失敗する）。参考→既存のLPGとルート表との関連付けのノート
どういう事かというと、以下のような構成で、VCN AからVCN B経由でVCN Cを通信させることはできず、別途VCN AとVCN Cをローカル・ピアリングゲートウェイで繋ぐ必要があります。
これ、なんでできないかと言うと、SpeakerDeckの資料を読む限りは「トランジット・ルーティング」を許可していないからですね。この考え方、他クラウドとのインターコネクトの場合とかも適用されます。例えば、オンプレからAzure経由でOCIと通信できない、とか（ProxyとかNAT使えば可）。これも試験に出ます。覚えましょう。
リモート・ピアリング接続を使った接続
動的ルーティング・ゲートウェイ（以下、DRG）を使った接続方式その１。
異なるリージョン間の接続の場合に使われる接続方式ですが、同一リージョンのVCNも接続できます。
（なぜかOCIのアイコン集にはありますが）リモート・ピアリング・ゲートウェイというリソースは存在しません。使うのはDRGの「リモート・ピアリング接続・アタッチメント」です。
ローカル・ピアリング・ゲートウェイと異なり、IPv4のCIDRが重複していても接続できますが、IPv4では通信できません。
こちらも異なるテナント間で接続する場合は、IAMの設定が必要です。
アタッチメント同士を接続するので、ゲートウェイに対する権限は不要みたいですね。
当然のようにDRGにも作成上限ありますので、同一リージョン内のVCN接続にこの方式はあまり使われないと思います。すでにDRGをアタッチしているVCN同士を接続する場合とかでしょうか。
あとは、DRGルート表をカスタマイズしたいときに、リモート・ピアリング接続を使ったほうが、インポートのルールが簡単になるケースはあるかもしれません。
VCNアタッチメントを使った接続
動的ルーティング・ゲートウェイ（以下、DRG）を使った接続方式その２。
同一リージョン内の接続の場合のみ使えます。DRGってVCNのリソースではなく、VCNアタッチメントというものを使ってVCNと接続し、VCNアタッチメントは複数作れることを利用した構成です。
これ、Oracle Cloud Infrastructure 202x Architect Professionalの実技試験にも出る構成なのに、紹介しているところ、すごい少ない気がするんですよね。
これも異なるテナント間で接続できます。IAMの設定はこちら。
同一リージョン内の接続ということで、ローカル・ピアリング・ゲートウェイを使った接続との違いが気になるところですが、以下の違いがあります。
- ローカル・ピアリング・ゲートウェイを使った接続は1対1の通信（接続しているVCN間の通信のみ許可される）となるが、VCNアタッチメントを使った接続は1対多になる
- VCNアタッチメントの場合、IPv4のCIDRが重複していても接続できる
- 一つのVCNにはVCNアタッチメントは一つしか作れない
Architect Professionalの実技試験で出るのは二つ目の話ですね。接続してもIPv4で通信はできませんが、IPv6では通信可能であることを利用して、ですね。
三つめは地味に盲点ですが、ローカル・ピアリング・ゲートウェイと組み合わせれば拡張できます。トランジット・ルーティングが許可されている構成です。
VCNアタッチメントを使ったハブ＆スポーク構成もあります。
ローカル・ピアリング・ゲートウェイとの違いの一つ目を使った例で、この場合のハブはVCNではなく、DRGです。
VCNアタッチメントも上限ありますが、ローカル・ピアリング・ゲートウェイに比べて一桁大きな値(Universal Creditsの場合)なので、上限を気にするケースの場合はこちらが良いと思います。難点は、通信制御をするためのDRGルート表が難解なこと、でしょうか。DRGルート表で制御するのはあきらめて、セキュリティ・リストやネットワーク・セキュリティ・グループ、VCNルート表で制御するほうが良いかもしれません。TCPはね、パケットが返ってこないと、通信成立できないんすよ。これも試験に出ます。いや、マジで。
FastConnectを使った接続
異なるリージョン間の接続の対抗馬。
帯域やレイテンシの観点では、リモート・ピアリング接続を使った接続と比べて利点があるケースはかなり限られていると思いますが、コスト面では利点があると思います。FastConnect、金額固定ですから。机上計算ですが、1Gbpsの回線を100%使い切れば、1ヶ月で300TB転送できるんですよ。
なお、この場合、OCIのAS番号は、リージョン関係なく同一(31898)なところに注意が必要です。例えば、BGPで経路情報を伝えている場合、AS PATHに31898が載っている経路情報を他リージョンに伝えても、破棄されます。これの対策としては、
- route-mapを使って、AS PATHから31898を削除する
- redistributeを使って、BGPじゃない区間を作る
- OCI全体で使うアドレス帯を作って広告する
あたりかなと思います。1つ目の場合は、ちょっと検証してみましたが、こんな感じかなあ？
OCI大阪から受け取ったルートにcommunity付与して、OCI東京向けのルート広告で、communityが付与されてたら31898を削除、って感じですね。
bgp community-list 2 seq 5 permit 65100:2
!
route-map OSAKA-IN permit 10
set community 65100:2
!
route-map OSAKA-IN permit 20
!
route-map TOKYO-OUT permit 10
match community 2
set as-path exclude 31898
set community none
!
route-map TOKYO-OUT permit 20
3つ目は思いっきり失念してましたが、OCI東京が10.0.0.0/16、OCI大阪が10.1.0.0/16だとして、10.0.0.0/15を流せば良いですね。若干制約はありますが。
あと、専用線サービスには、オンプレと複数のクラウドを接続するサービスを提供しているところも多数あるので、その中には、CPE経由せずに、サービスネットワーク内で折り返せるところもあるんじゃないかなと妄想はするんですが、実際のところ、どうなんでしょうね？さすがに個人でFastConnect契約するのはちょっと無理なので、実績ある人はこそっと教えてくれると嬉しいです。
まとめ
思った以上に「試験に出ます」項目が多くて、自分でもびっくりしました。