OCIネットワーク実践Vol1 LB設計とDRGルーティング実装

1. この記事について — OCIネットワークを「本番設計」の深さで実践する

1-1. 本記事のゴール — 全体スコープの宣言

本記事は、「OCIネットワーク実践(Production編)」シリーズの第1弾として、OCI入門シリーズVol3で扱ったVCN・サブネット・ゲートウェイの基礎の先にある、本番運用を見据えたネットワーク設計を実装レベルで一気通貫に扱います。

本記事はここで宣言する通り、§2から§6までを1本の記事として完結させます。

• §2: Flexible Load Balancer / Network Load Balancerの設計実践(AWSのALB/NLBとの対比を含む)
• §3: DRG(Dynamic Routing Gateway)のルートテーブル・アタッチメント設計実践
• §4: FastConnectによるオンプレミス/他ネットワーク接続の設計実践
• §5: VCNピアリング(ローカルピアリング・リモートピアリング)の設計実践
• §6: ここまでの経路設計の統合と冗長化構成、本記事のまとめ

本記事を読み終えると、次の状態になることを目指しています。

• Flexible LBとNLBを、AWSのALB/NLBとの役割の近さ・違いを踏まえて使い分けられる
• DRGルートテーブルのimport/exportルート配信の考え方を理解し、ハブアンドスポーク構成でスポーク間通信を意図通りに許可・遮断できる
• FastConnect・VCNピアリングを含めた経路設計全体を俯瞰し、単一障害点を排した冗長化構成を検討できる

なお本記事は、Always Free枠で実演可能な範囲(Flexible LB 1台・NLB 1台)は実際に構築しながら解説しますが、FastConnectや複数DRGアタッチメントによる冗長構成など、有償リソースを要する部分は設計・構成の考え方を実装レベルで解説する形を取ります(§4以降で詳細を扱います)。

1-2. 読者像

本記事は、AWSでALB(Application Load Balancer)・NLB(Network Load Balancer)・Transit Gateway・VPCピアリングの設計や運用に携わった経験があり、OCIでも同等レベルの本番運用設計をしたいと考えているエンジニアを主な読者として想定しています。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIのFlexible Load BalancerはAWSのALBと同じものと考えてよいのか、それとも別の使い分けが必要なのか
• DRGは、AWSのVGW(Virtual Private Gateway)とTransit Gatewayのどちらに近いのか
• Always Free枠だけでどこまで本番相当の構成を検証でき、どこから有償リソースが必要になるのか
• ハブアンドスポーク構成で、スポークVCN同士の直接通信を意図せず許可してしまわないか

なお、本記事は「OCI入門」シリーズVol3(VCN・サブネット・ゲートウェイ・セキュリティ)を読了済みであることを前提としていますが、DRGの基本的な役割など、Vol3が触れた範囲の要点は本章で簡潔に振り返ります。Vol3が扱った内容(サブネットの区分・IGW/NAT Gateway/Service Gatewayの基礎・セキュリティリストの基礎)そのものの再説は行いません。

1-3. 本記事の位置づけ — OCI入門シリーズVol3との関係

「OCI入門」シリーズVol3は、VCN・サブネット・4種類のゲートウェイ(Internet Gateway・NAT Gateway・Service Gateway・DRG)の基礎を扱い、DRGについては「オンプレミス環境や他のVCN・他リージョンとの接続を1つの入口に集約する仮想ルーター」として、その役割を1段落で紹介するにとどまっていました。

本記事は、その続きとして、Vol3が入口までしか踏み込まなかったDRGを、ルートテーブル設計・アタッチメント設計・ECMP・ハブアンドスポーク構成という実装レベルまで掘り下げます。加えて、Vol3では扱わなかったロードバランサー(Flexible LB/NLB)の設計実践も本記事のスコープに含めます。

Vol3を未読の場合でも、DRGの基本的な役割やVCN・サブネットの基礎用語については本記事の各章で必要な範囲を補足しますが、より体系的な基礎固めをしたい場合はVol3を先に参照することをお勧めします。

1-4. 本記事の差別化軸

OCIのネットワークサービスを扱う記事の多くは、コンソールでの作成手順の紹介にとどまるか、逆にDRGやFastConnectといった個々のサービスを単体で深掘りするに留まりがちです。本記事は、次の3つの軸で差別化を図ります。

1. AWSネットワークエンジニア向けの役割対比レンズ: 「名前が似ているから機能も同じ」という誤解を避けるため、AWSの対応サービスとは「厳密な1:1」ではなく「役割が近い対応」として整理します。特にFlexible LBはL7(HTTP/HTTPS)だけでなくL4(TCP)リスナーも持つ点、DRGはAWSのVirtual Private GatewayとTransit Gatewayの役割を統合した存在である点は、誤解が生じやすいため本記事で正面から扱います。
2. LB・DRG・FastConnect・ピアリング・冗長化の一気通貫実装: 個々のサービスを単体で終わらせず、§2〜§6を通じて「本番運用に耐えるネットワーク設計」を1つの構成として組み立てます。
3. Always Free枠の範囲を正確に切り分ける: Flexible LB(帯域10Mbps固定)とNLBはAlways Free枠で実際に構築して検証できますが、帯域固定などの制約を曖昧にせず、有償リソースが必要になる境界線を明示します。

1-5. AWSネットワークサービスとの役割対応(概観)

本記事で扱うOCIサービスと、AWSの対応サービスの役割の近さを、まず概観として整理します。厳密な1:1対応ではなく、あくまで「近い役割を持つサービス」としての対応関係である点に注意してください。個々の相違点は、各章で具体的に扱います。

この表が示す通り、OCIではAWSにおけるVGWとTransit Gatewayの2つの役割を、DRGという単一のリソースが統合的に担う点が特徴的な違いです。この違いは§3で具体的に掘り下げます。

1-6. 用語整理 — DRGアタッチメントの種類

DRGには複数の種類の「アタッチメント」が存在し、章によって扱う対象が異なります。混乱を避けるため、本記事全体で使う用語を先に整理しておきます。

• VCNアタッチメント: DRGとVCNを接続するアタッチメント。§3で扱います。
• IPSecトンネルアタッチメント: Site-to-Site VPN接続用のアタッチメント。§3で概要とルートテーブルの考え方を扱います。
• Virtual Circuitアタッチメント: FastConnectの専用線接続用のアタッチメント。§4で詳しく扱います。
• Remote Peering Connection(RPC)アタッチメント: 他リージョン・他テナンシのDRGとのピアリング用のアタッチメント。§5でVCNピアリングと合わせて扱います。

これらのアタッチメントはすべて、DRGが持つルートテーブルによって経路制御を受けます。この共通の仕組みを§3でまず理解しておくと、§4・§5で個別のアタッチメント種別を扱う際にも、同じルートテーブルの考え方の応用として理解しやすくなります。

1-7. 前提とする環境

本記事は、「OCI入門」シリーズVol1(テナンシ・コンパートメント・Always Free枠)およびVol2(IAM・ポリシー)で扱った、テナンシのサインアップとコンパートメント設計、ネットワークリソースを操作するためのIAMポリシーが整備済みであることを前提とします。

また、Vol3で作成したVCN・サブネットを前提として、その上にロードバランサーやDRGを追加していく構成で解説を進めます。VCN・サブネット自体を新規に作り直す必要はありませんが、既存のVCNがない場合はVol3の手順に沿って作成しておいてください。

リージョンについては、本記事の§2(Flexible LB/NLB)は東京リージョンで完結しますが、§4で扱うFastConnectは拠点が限られるため、リージョンの選定についても§4で改めて扱います。

なお、AWS実務者がOCIのネットワークリソースを初めて触る場合、コンソールのメニュー構成がAWSのVPCコンソールとは異なる点に戸惑うことがあります。この点についても、各章の構築手順の中で必要に応じて補足します。

→ OCI入門 Vol3: VCN・サブネット・ゲートウェイ・セキュリティ

それでは、まずFlexible Load BalancerとNetwork Load Balancerの設計実践から見ていきましょう。

2. Flexible Load Balancer / Network Load Balancer 設計実践

本章では、OCIの2種類のロードバランシングサービス、Flexible Load Balancer(以下、Flexible LB)とNetwork Load Balancer(以下、NLB)を、AWSのALB/NLBとの役割対比を交えながら設計・構築します。まず両サービスの仕様を正確に押さえたうえで、Always Free枠で実演します。

2-1. Flexible Load Balancerの仕様 — AWS ALBとの役割対比

Flexible LBは、OCIにおけるL7(HTTP/HTTPS)およびL4(TCP)のロードバランシングを1つのリソースで提供するサービスです。ここで重要な注意点があります。Flexible LBは「AWSのALBに相当する」とだけ理解すると、TCPリスナーを持つ点を見落としてしまいます。

Flexible LBという名前の「Flexible」は、帯域(シェイプ)を柔軟に設定できることに由来します。有償枠では、最小帯域と最大帯域をそれぞれ10Mbpsから8,000Mbpsの範囲で指定でき、最小帯域は常に確保された状態で利用できます。

Always Free枠のFlexible LBは、帯域が最小・最大ともに10Mbpsで固定されており、有償枠のように帯域を引き上げることはできません。検証用途や低トラフィックの用途には十分ですが、本番トラフィックを想定する場合は、有償枠に切り替えて帯域を引き上げる設計が前提になります。この帯域固定という制約を把握しないまま「無料枠のまま帯域を後から拡張する」という設計をしてしまうと、本番移行時に手戻りが発生するため、設計の初期段階で有償枠への切り替えタイミングを明確にしておくことが重要です。

2020年12月15日より前に作成されたテナンシでは、Flexible LBではなくMicroシェイプ(帯域10Mbps・リスナー10・バーチャルホスト名10・バックエンドセット10・バックエンドサーバー128)のロードバランサーが提供される点にも触れておきます。本記事はFlexible LBを前提に解説します。

2-2. Network Load Balancerの仕様 — AWS NLBとの役割対比

NLBは、L3/L4に特化したロードバランシングサービスで、送信元IPアドレスを保持したままバックエンドへ転送する点が特徴です。この特性は、AWSのNLBと同様の設計思想です。

NLBはFlexible LBと異なり帯域シェイプの指定という概念を持たず、リスナー・バックエンドセットの上限がFlexible LBよりも大きく設定されています。「無料でも帯域固定に縛られたくない」「送信元IPをそのままバックエンドで見たい」というケースでは、NLBが有力な選択肢になります。

NLBはL3/L4に特化しているため、SSL/TLSの終端機能を持ちません。HTTPS通信をNLB配下で扱う場合は、バックエンド側のコンピュートインスタンスやコンテナでTLS終端を行う設計になります。この点は、TLS終端を担えるAWSのNLB(TLSリスナーでの終端が可能)とは異なる部分であり、AWSでNLBのTLSリスナーを使っていたチームがOCI移行時に見落としやすいポイントです。

2-2-1. NLBのユースケース — OKE(Kubernetesサービス)との関係

補足として、NLBはOCIのマネージドKubernetesサービスであるOKE(Oracle Container Engine for Kubernetes)において、Service リソース(type: LoadBalancer)を作成した際にデフォルトで作成されるロードバランサーの実体でもあります。AWSのEKSでALB IngressやNLBをアノテーションで使い分けるのと同様に、OKEでもアノテーションによってFlexible LB/NLBのどちらを使うかを選択できます。本記事ではOKEそのものは扱いませんが、コンピュートインスタンス相手のバックエンドセットと同じ考え方が、OKEのバックエンド(Pod/Node)にもそのまま当てはまります。

2-3. Flexible LBとNLBの使い分け

ここまでの仕様を踏まえ、Flexible LBとNLBの使い分けの指針を整理します。

• HTTP/HTTPSのパスベースルーティングやSSL終端など、L7の機能が必要な場合はFlexible LB一択です(NLBにL7機能はありません)
• 送信元IPの保持が必須の要件(バックエンド側でクライアントIPベースのアクセス制御を行う場合など)は、NLBが適しています
• 純粋なTCPロードバランシングで、L7機能もリスナー数の余裕も必要な場合は、Flexible LBのTCPリスナーとNLBのどちらでも実現できますが、Always Free枠の帯域固定を避けたい場合はNLBが有利です

2-3-1. 負荷分散アルゴリズムとヘルスチェックの比較

Flexible LB/NLBのバックエンドセットでは、次の負荷分散ポリシーを選択できます。

ヘルスチェックは、プロトコル(TCPまたはHTTP)・ポート・(HTTPの場合は)パス・実行間隔・タイムアウト・リトライ回数・期待するレスポンスコードを設定します。AWSのALB/NLBのヘルスチェック設定と考え方はほぼ同じですが、OCIではこれらの設定項目がバックエンドセット単位でまとめて管理される点を押さえておくと、コンソール操作時に迷いにくくなります。

2-4. Always Free枠での構築実践 — Flexible LB

ここからは実際に、Always Free枠でFlexible LBを構築します。前提として、Vol3で作成したVCN・パブリックサブネットが存在することを確認してください。

1. OCIコンソールで「ネットワーキング」→「ロードバランサー」→「ロードバランサーの作成」を選択します
2. ロードバランサーのタイプで「ロードバランサー」(Flexible LB)を選択します
3. シェイプでFlexible LBを選択し、最小帯域・最大帯域をともに10Mbpsに設定します(Always Free枠の上限を超えると有償扱いになるため、必ず10Mbps/10Mbpsで作成してください)
4. パブリック/プライベートの区分でパブリックを選択し、Vol3で作成したVCN・パブリックサブネットを指定します
5. リスナーの設定でプロトコルにHTTPを選択し、ポート80を指定します(HTTPSを使う場合は証明書の設定が別途必要になります)
6. バックエンドセットの作成で、負荷分散ポリシー(2-3-1で整理したいずれか)とヘルスチェックを設定し、バックエンドとなるコンピュートインスタンスを登録します
7. HTTPSリスナーを追加する場合は、証明書の設定でOCIのCertificatesサービス(AWSのACMに近い役割)から発行した証明書、または自己所有の証明書をインポートして割り当てます
8. 必要に応じて、バックエンドセットでセッションパーシステンス(クッキーベースのスティッキーセッション)を有効化します。AWSのALBにおけるスティッキーセッションと同様の考え方です

作成後、ロードバランサーの詳細画面でパブリックIPアドレスが払い出されていることを確認し、そのIPアドレスへのHTTPリクエストがバックエンドへ正しく分散されることを確認します。

2-5. Always Free枠での構築実践 — NLB

続いてNLBを構築します。手順の骨格はFlexible LBと似ていますが、NLBはL3/L4専用であるため、リスナーの設定が異なります。

1. 「ネットワーキング」→「ロードバランサー」→「ネットワークロードバランサーの作成」を選択します
2. パブリック/プライベートの区分と、Vol3で作成したVCN・サブネットを指定します
3. リスナーの設定でプロトコル(TCPまたはUDP)とポートを指定します
4. 「送信元/宛先チェックの保持」に関するオプションを確認し、送信元IPアドレスをそのままバックエンドへ届けたい場合は既定の挙動(保持あり)のままにします
5. バックエンドセットの作成で、負荷分散ポリシー(2-3-1参照)とヘルスチェックを設定し、バックエンドとなるコンピュートインスタンスを登録します
6. バックエンド側のセキュリティリスト/NSGで、クライアントの実IPからの通信を許可するルールを設定します(NLBのIPではなく実クライアントのCIDRを意識する必要がある点は2-6で扱った通りです)

作成後、NLBのパブリックIPアドレス宛のトラフィックが、送信元IPアドレスを保持したままバックエンドへ転送されることを、バックエンド側のアクセスログで確認します。

2-5-1. 動作確認 — Flexible LBとNLBの送信元IPの違いを比較する

実際に構築が完了したら、両方のロードバランサー経由でバックエンドへアクセスし、バックエンド側で観測される送信元IPアドレスの違いを比較します。

# Flexible LB経由でアクセス(HTTPリスナー)
curl -s http://<FLEXIBLE_LB_PUBLIC_IP>/ -H "Host: example.internal"

# NLB経由でアクセス(TCPリスナー、簡易HTTPサーバーで確認する場合)
curl -s http://<NLB_PUBLIC_IP>:<LISTENER_PORT>/

バックエンド側(例えばNginxのアクセスログや X-Forwarded-For ヘッダー)を確認すると、Flexible LB経由ではロードバランサーが送信元IPを終端して転送するのに対し、NLB経由ではクライアントの実IPアドレスがそのままバックエンドに届いていることが確認できます。この違いを実機で確認しておくと、後続のセキュリティ設計(アクセス制御をどちらの層で行うか)を判断しやすくなります。

2-6. 構築時によくある落とし穴

• Always Free枠を超える帯域設定: Flexible LBの帯域を10Mbpsより大きく設定すると、その時点で有償リソースとして扱われます。Always Free枠での検証時は、作成時・変更時の両方で帯域設定を確認してください
• セキュリティリストの設定漏れ: ロードバランサーのサブネットとバックエンドのサブネットの両方で、ロードバランサーからバックエンドへのヘルスチェック・トラフィックを許可するセキュリティリスト(またはNSG)の設定が必要です。AWSのALB/NLBのようにセキュリティグループが自動的に補完してくれるわけではないため、明示的な設定が必要です
• ヘルスチェックの設定不備によるバックエンド全滅: ヘルスチェックのパスやポートがバックエンドの実際の状態と一致していないと、バックエンドが「異常」と判定され続け、トラフィックが一切転送されない状態になります
• パブリック/プライベートの選択ミス: 作成時にパブリック/プライベートの区分は変更できません。内部向けのロードバランサーを誤ってパブリックで作成してしまうと、作り直しが必要になります
• NLBで送信元IP保持を前提にしたセキュリティ設計をしていない: NLBは送信元IPを保持したままバックエンドへ転送するため、バックエンド側のセキュリティリスト/NSGで許可するCIDRは、ロードバランサーのIPではなく実際のクライアントのCIDR範囲を考慮した設計が必要です

2-7. 可用性設計 — フォルトドメインを使ったバックエンド冗長化

AWSのMulti-AZ構成に慣れた方が特に注意すべき点として、東京リージョン(ap-tokyo-1)はアベイラビリティドメイン(AD)が1つしか存在しません(フォルトドメインなら1つのADの中に3つ存在します)。「AWSと同じ感覚でAZを分けてバックエンドを冗長化する」という設計はそのまま成立せず、OCI東京リージョンではフォルトドメイン(Fault Domain)単位での冗長化が基本になります。

Flexible LB/NLBのバックエンドセットにインスタンスを登録する際は、異なるフォルトドメインのインスタンスを組み合わせることを意識してください。これはAWSでいう「異なるAZにまたがるターゲットグループ」に近い考え方ですが、東京リージョンでは「AD」ではなく「フォルトドメイン」が冗長化の単位になる点が異なります。

2-8. WAF(Web Application Firewall)との連携

OCIのWAF(Web Application Firewall)は、AWSのWAF(+ALBへのアタッチ)に近い役割を持つサービスで、Flexible LBに対してWAFポリシーをアタッチする形で連携します。WAFポリシーには、リージョナルな「LBaaS向けWAFポリシー」と、グローバルなエッジ型の「Edge WAFポリシー」の2種類があり、リージョン内で完結する用途にはLBaaS向けWAFポリシーを、グローバルに分散したユーザー向けにはEdge WAFポリシーを使い分けます。本記事ではFlexible LB/NLBの構築までを扱うため、WAFの詳細設定は扱いませんが、本番運用ではFlexible LBに対してWAFポリシーをアタッチする構成を検討することをお勧めします。

2-9. コスト設計の考え方 — Always Freeから有償枠への切替

Flexible LBは基本料金に加えて設定帯域(Mbps)に応じた従量課金、NLBは処理データ量に応じた従量課金という、課金体系そのものが異なるサービスです。具体的な単価は変更される可能性があるため、本記事では金額を明記せず、設計判断に必要な考え方のみを整理します。

• Flexible LBは帯域を固定的に確保する課金モデルのため、トラフィックの急激な増減が予想される場合は、事前に必要な帯域を見積もった上で最小/最大帯域を設定する必要があります
• NLBは処理データ量に応じた従量課金のため、帯域を事前に見積もる必要がない一方、想定外の大量トラフィックが発生した場合のコスト増を監視する仕組み(コストアラートなど)を別途用意しておくことをお勧めします
• Always Free枠は帯域・リスナー数などに明確な上限があるため、本番移行の判断基準として「どの上限に近づいたら有償枠へ切り替えるか」を事前に決めておくと、移行のタイミングで慌てずに済みます

2-9-1. AWS ALBとの自動スケーリングの考え方の違い

AWSのALBは、トラフィックの増減に応じてAWS側が自動的にキャパシティをスケールする、完全マネージドな自動スケーリングモデルです。利用者側が帯域やキャパシティユニットを事前に指定する必要は基本的にありません。

一方OCIのFlexible LBは、名前の「Flexible」が示す通り帯域を柔軟に変更できる一方、その変更(最小/最大帯域の引き上げ)はコンソールやAPI経由で利用者が能動的に実施する操作です。トラフィックの急増を検知して自動的に帯域を引き上げる仕組みは標準では備わっていないため、本番運用ではモニタリング(帯域使用率のアラート等)と組み合わせて、必要に応じて帯域を引き上げる運用フローをあらかじめ設計しておく必要があります。この「自動 vs 手動(アラート駆動)」というスケーリングモデルの違いは、AWSのALBに慣れたチームがOCIへ移行する際に見落としやすいポイントです。

2-10. 本章のまとめ

本章では、Flexible LBとNLBの仕様をAWSのALB/NLBと対比しながら整理し、Always Free枠での構築・動作確認、可用性設計・WAF連携・コスト設計の考え方まで扱いました。最後に、本章で扱った特性を1つの表に整理します。

それでは次に、本記事のもう1つの主題であるDRG(Dynamic Routing Gateway)のルートテーブル設計・アタッチメント設計を、§3で実装レベルまで掘り下げていきます。

3. DRG(Dynamic Routing Gateway)設計実践

本章では、「OCI入門」シリーズVol3で役割紹介にとどまっていたDRG(Dynamic Routing Gateway)を、ルートテーブル・アタッチメント・ECMP・ハブアンドスポーク構成という実装レベルまで掘り下げます。

3-1. DRGの役割再確認 — AWSのVGW+Transit Gatewayを統合した存在

DRGは、VCNと、オンプレミス環境・他のVCN・他リージョンとの接続を1つの入口に集約する仮想ルーターです。§1-5で整理した通り、DRGはAWSにおける2つの異なるサービスの役割を1つのリソースに統合している点が最大の特徴です。

この統合的な設計により、OCIではまず1つのDRGを作成し、そこにVCN・IPSecトンネル・FastConnect・リモートピアリングといった複数の種類のアタッチメントを追加していくという、一貫したメンタルモデルで設計を進められます。この点が、VGWとTGWを別々に設計するAWSとの大きな違いです。

3-2. DRGアタッチメントの種類(再掲と補足)

§1-6で整理した通り、DRGには5種類のアタッチメントがあります。本章では、このうちVCNアタッチメントとIPSecトンネルアタッチメントを中心に扱います(Virtual CircuitアタッチメントはFastConnectとして§4、Remote Peering ConnectionアタッチメントはVCNピアリングとして§5で扱います)。

• VCNアタッチメント: DRGとVCNを接続します。1つのDRGは複数のVCNアタッチメントを持つことができ、ローカルピアリングゲートウェイ(LPGは1つのVCNあたり最大10個までの接続に限られる)よりも大規模なVCN数を一元管理できます
• IPSecトンネルアタッチメント: Site-to-Site VPN接続用のアタッチメントです
• Loopbackアタッチメント: FastConnectの仮想回線を暗号化する用途で使用します

3-3. DRGルートテーブルの設計

DRGの中核となるのがルートテーブルです。DRGアタッチメントごとに個別のルートテーブルを割り当てることができ、同じルートテーブルを複数のアタッチメントで共有できます。DRGを新規作成すると、VCNアタッチメント用とその他のアタッチメント用の、2つのデフォルトルートテーブルが自動生成されます。

DRGルートテーブルの経路は、静的ルートと動的ルートの2種類で構成されます。動的ルートは、各アタッチメントの先にあるネットワーク(VCNのサブネットCIDR、IPSecトンネルの先のオンプレミスCIDR等)から自動的に学習され、この学習の挙動を制御するのが「インポートルート配信(Import Route Distribution)」です。

VCNアタッチメントについては、DRG側とVCN側それぞれにルートテーブルが存在する「双方向」の構造になっている点にも注意してください。DRG側のルートテーブルはVCNから出ていくトラフィックの経路(DRGへのイングレス)を、VCN側のルートテーブルはDRGから戻ってくるトラフィックの経路(VCNへの着信)を制御します。

3-4. ハブアンドスポーク構成とスポーク間の通信制御

DRGを使ったハブアンドスポーク構成は、複数のVCN(スポーク)をDRG(ハブ)に接続し、スポーク同士を直接ピアリングせずにDRG経由で通信させる構成です。AWSのTransit Gatewayを使ったハブアンドスポーク構成と設計思想は同じですが、DRGには次のようなデフォルトの経路伝播制限があります。

つまり、何も設定しなければ、オンプレミス拠点A(IPSec接続)からオンプレミス拠点B(別のIPSec接続)への通信はDRGを経由して自動的に成立しません。この制限は、意図しないオンプレミス間のトランジット通信を防ぐための安全機構です。一方でVCNアタッチメント同士の通信可否は、インポート/エクスポートルート配信の設定次第で、許可も遮断も可能です。

スポークVCN同士の直接通信を遮断し、必ずハブVCN(ネットワーク仮想アプライアンスなどを配置したインスペクション用VCN)を経由させたい場合は、次のような設計になります。

1. 各スポークVCNのルートテーブルには、他のスポークVCNのCIDRへの経路を直接エクスポートせず、ハブVCN経由の経路のみをインポートさせる
2. ハブVCN側で、スポークVCN間のトラフィックを検査・フィルタリングするネットワーク仮想アプライアンス(ファイアウォール等)を経由させる
3. インポート/エクスポートルート配信のマッチ条件で、アタッチメントの種別・OCIDを指定し、優先度(数値が小さいほど高優先度)を明示的に設計する

3-5. ECMP(Equal-Cost Multi-Path)による帯域の拡張

DRGは、IPSecトンネルまたはFastConnectの仮想回線に対して、ECMP(等コストマルチパス)を有効化できます。ECMPを使うと、複数の回線に対してフローベースでトラフィックを分散させる、アクティブ・アクティブ構成が可能になります。

ECMPは、AWSでいえば複数のSite-to-Site VPNトンネルやTransit Gatewayの複数アタッチメントを使った帯域拡張・冗長化の考え方に近いものです。1本のIPSecトンネルやFastConnect回線では帯域が不足する場合、または単一回線の障害への備えが必要な場合、ECMPを有効化した複数回線構成を検討します。

3-6. 設計時によくある落とし穴

• ルートテーブルの優先度設定ミス: インポートルート配信の優先度(数値が小さいほど高優先度)を誤って設定すると、意図した経路が学習されず、想定外の経路でトラフィックが流れる、または疎通しないという事象が発生します
• スポーク間通信が意図せず成立してしまう: エクスポートルート配信の設定を見落とすと、本来遮断したいスポークVCN間の通信が、経路上は成立してしまう場合があります。ハブアンドスポーク構成では、経路レベルの遮断とセキュリティリスト/NSGレベルの遮断を両方設計することをお勧めします
• オンプレミス間トランジットができないと誤解する / 依存してしまう: 3-4で触れた通り、IPSec/Virtual Circuitアタッチメント同士の直接トランジットはデフォルトで不可です。この制限を理解せずに「DRG経由でオンプレミス拠点同士を中継できるはず」という設計をしてしまうと、疎通試験の段階でつまずきます
• ECMPの回線種別混在: IPSecトンネルとFastConnect仮想回線を混在させたECMPは構成できません。冗長化の設計時は、同一種別の回線で揃える必要があります

→ OCI入門 Vol3: VCN・サブネット・ゲートウェイ・セキュリティ

ここまでで、Flexible LB/NLBによるロードバランシング設計と、DRGのルートテーブル・アタッチメント・ECMP・ハブアンドスポーク設計を扱いました。続く§4では、DRGのVirtual CircuitアタッチメントによるFastConnect接続の設計実践に進みます。

4. FastConnectによる接続実践

本章では、§1-6・§3-2で「Virtual Circuitアタッチメント」として位置づけたFastConnectを、接続方式の選び方から設計レベルで掘り下げます。FastConnectはオンプレミス環境や他のデータセンターとOCIを、インターネットを経由しない専用線接続でつなぐサービスであり、AWSのDirect Connectに役割が近いサービスです。なお、FastConnectは物理的な回線敷設・相互接続を伴うため、本記事のようなAlways Free枠中心の検証環境で実演できません。本章は、設計・手順の解説に専念します。

4-1. FastConnectの3つの接続方式

FastConnectは、次の3つの接続方式のいずれかで構成します。

物理ポートの速度は、パートナー経由では1/10/100 Gbps、サードパーティプロバイダー経由およびコロケーションでは最大400 Gbpsまでの選択肢が提供されています(2026年7月26日時点の公式ドキュメント)。仮想回線(Virtual Circuit)単位の帯域は、パートナー/プロバイダーごとに提供される帯域シェイプから選択します。複数の仮想回線を束ねることで、さらに大きな帯域を確保できます。

4-2. 接続拠点の具体例(取得日: 2026年7月26日)

FastConnectの接続拠点は、リージョンごとに利用可能なデータセンター・パートナーが異なります。2026年7月26日時点でOCI公式のFastConnectパートナー/ロケーション一覧ページを確認したところ、東京リージョンでは Equinix TY4、NEC 印西データセンター SI3 が、大阪リージョンでは NTT Data 堂島4 が、それぞれFastConnect接続拠点として掲載されています。実際の拠点選定にあたっては、自社の既存データセンター・オフィスからの物理的な距離や、契約しているキャリアがそのロケーションに乗り入れているかを確認する必要があるため、設計の初期段階で公式ページの最新情報を確認することをお勧めします。

4-3. AWS Direct Connectとの対比 — hosted接続とdedicated接続

FastConnectの3つの接続方式は、AWSのDirect Connectが提供する接続方式と役割が近い対応関係にあります。

この対応関係も、§1-5・§3-1で整理した他の対比と同様、厳密な1:1ではなく役割が近い対応として捉えてください。特にAWSのhosted接続では、パートナーの持つ帯域を複数顧客で分割して提供します。一方FastConnectパートナー経由の接続は、パートナーごとに提供形態が異なるため、契約時にパートナー側の資料で提供帯域の考え方を確認することをお勧めします。

4-4. Virtual Circuitアタッチメントの設計 — Private/Publicピアリング

FastConnectで確立した物理接続の上に、論理的な仮想回線として「Virtual Circuit」を作成し、DRGのVirtual Circuitアタッチメントとして接続します。Virtual Circuitには、次の2種類のピアリングタイプがあります。

• プライベートピアリング: VCN内のプライベートIPリソースへ、プライベートIPアドレスのまま到達するための接続です。オンプレミスとVCN間の通常のネットワーク接続はこちらを使います
• パブリックピアリング: Object Storageなど、OCIのパブリックサービスエンドポイントへ、インターネットを経由せずFastConnect経由で到達するための接続です

AWSでも、Direct Connectにプライベート仮想インターフェース(プライベートVIF)とパブリック仮想インターフェース(パブリックVIF)という同様の区分があり、この対比は分かりやすい共通点です。

DRG側では、Virtual CircuitアタッチメントもVCNアタッチメント・IPSecトンネルアタッチメントと同じDRGルートテーブルの仕組みで経路制御を受けます(§3-3参照)。FastConnect経由で学習した経路をどのVCNへエクスポートするか、逆にVCN側のどの経路をFastConnect経由でオンプレミスへエクスポートするかは、インポート/エクスポートルート配信で設計します。

4-5. 設計時によくある落とし穴

• 単一回線・単一拠点への依存: FastConnectは物理接続であるため、回線の切断や拠点の障害がそのまま接続断につながります。本番運用では、後述する§6のECMP・複数拠点構成による冗長化を前提に設計してください
• BGPアドバタイズ範囲の設計漏れ: FastConnectはBGPで経路を交換するため、オンプレミス側から意図しない広い範囲のCIDRをアドバタイズしてしまうと、DRGルートテーブル経由で想定外のVCNまで経路が伝播しかねません。§3-4で整理したインポート/エクスポートルート配信の設計を、FastConnect回線でも同様に適用してください
• 課金対象の見誤り: FastConnectの回線自体(パートナー利用料・ポート利用料等)は有償です。一方、DRGのアタッチメント自体やVCN間の通信そのものに個別の課金が発生するかどうかは、リソースの組み合わせや契約条件によって変わり得るため、本記事では断定を避けます。設計・見積もりの段階では、必ずOCI公式の価格表で最新の課金体系を確認してください

それでは次に、§5でVCN間のピアリング設計を、DRG経由の方式を中心に見ていきます。

5. VCNピアリングの実装

本章では、VCN同士を接続するピアリングの実装を扱います。OCIには、Local Peering Gateway(LPG)を使う方式と、DRGを使う方式の2種類がありますが、本章ではDRG経由の方式を主軸に据えて解説します。

5-1. OCIのVCN間接続 2つの方式

§3-2で触れた通り、LPGは1つのVCNあたり最大10個までの接続に限られる点対点の方式です。VCN数が増えるほど、LPGの組み合わせはVCN数の2乗のオーダーで増加し、管理が複雑になります。一方DRG経由であれば、VCNをDRGに接続するだけで、あとはDRGルートテーブルのインポート/エクスポートルート配信の設計だけで、どのVCN同士を通信させるかを一元的にコントロールできます。この特性から、新規設計ではDRG経由のハブアンドスポーク構成を基本方針とすることを推奨します。

5-2. 同一リージョン内のVCN間通信 — DRGをハブとした実装

同一リージョン内の複数VCNをDRG経由で通信させる実装自体は、§3で解説したVCNアタッチメントの追加と、DRGルートテーブルの設計がそのまま該当します。

1. 通信させたい各VCNを、同一のDRGにVCNアタッチメントとして接続します(§3-2)
2. 各VCNアタッチメントに割り当てるDRGルートテーブルを設計し、通信を許可したいVCN同士の経路が、インポートルート配信で互いのDRGルートテーブルへ学習されるようにします(§3-3)
3. 通信を許可しないVCN同士については、インポートルート配信のマッチ条件から除外することで、経路レベルで遮断します

この設計により、点対点のLPGを都度作成することなく、DRGルートテーブル1箇所の設定変更だけで、VCN間の通信可否を柔軟にコントロールできます。§3-4で扱ったハブアンドスポーク構成のスポーク間通信制御と、本質的に同じ設計手法です。

5-3. 異なるリージョン・異なるテナンシ間の通信 — Remote Peering Connection

異なるリージョンのVCN同士、または異なるテナンシに属するVCN同士を接続する場合は、Remote Peering Connection(RPC)アタッチメントを使います。

1. 接続する双方のリージョン(またはテナンシ)のDRGに、それぞれRPCアタッチメントを作成します
2. 一方のRPCアタッチメントから、もう一方のRPCアタッチメントへ接続をリクエストし、相手側で接続を承認します(異なるテナンシの場合は、事前にIAMポリシーで相手テナンシとのピアリングを許可しておく必要があります)
3. 接続確立後は、通常のDRGアタッチメントと同様に、DRGルートテーブルのインポート/エクスポートルート配信で経路を制御します

RPCアタッチメントで学習した経路も、§3-3で解説したDRGルートテーブルの仕組みに統合される点が重要です。つまり、FastConnect(§4)・IPSecトンネル・VCNアタッチメント・RPCアタッチメントのすべてが、同じDRGルートテーブルという1つの仕組みの上で経路制御される一貫した設計になります。

5-4. LPGの位置づけ — 従来手法としての扱いと移行の論点

LPGは、DRGが複数VCNアタッチメントやルートテーブルをサポートする前から存在する、従来からのピアリング手法です。単純に2つのVCNを1対1で接続するだけの小規模な構成であれば、LPGは現在でも有効な選択肢ですが、OCI公式ドキュメントでも、複数VCNを一元管理する新規設計では、DRGを使ったハブアンドスポーク構成への移行が案内されています。

なお、2021年前後より以前に作成されたDRGの中には、複数のVCNアタッチメントやDRGルートテーブルといった機能に対応しない古い世代のものも見られます。既存のDRGを流用してDRG経由のピアリングへ移行する際は、対象のDRGが複数VCNアタッチメント・ルートテーブル機能に対応しているかを事前に確認し、対応していない場合はアップグレードの要否を検討してください。この論点は本記事の主眼ではないため、詳細な手順には立ち入りませんが、既存環境を扱う際に見落としやすいポイントとして触れておきます。

5-5. AWS VPC Peeringとの対比

AWSのVPC Peeringは、同一リージョン・インターリージョンのいずれであっても常に点対点の接続であり、トランジット(中継)通信をサポートしない点が特徴です。複数VPCを集約したい場合は、別リソースであるTransit Gatewayを組み合わせる必要があります。一方OCIでは、DRGという単一のリソースが、点対点のリモートピアリング(RPC)と、複数VCNの集約管理(VCNアタッチメント+ルートテーブル)の両方を担える点が、§1-5・§3-1で整理したDRGの統合的な性格と一致します。

5-6. 実装時によくある落とし穴

• LPGとDRGの経路が混在して管理が煩雑になる: 一部のVCN間はLPG、別のVCN間はDRG経由、というように方式が混在すると、経路の全体像を把握しづらくなります。新規構成ではDRG経由に統一することをお勧めします
• RPC接続の承認待ちで作業が止まる: 異なるテナンシ間のRPC接続では、相手側テナンシの管理者による承認が必要です。事前に相手側と作業タイミングをすり合わせておかないと、接続確立までに想定外の待ち時間が発生します
• 異なるテナンシ間のIAMポリシー未設定: RPCアタッチメントの接続自体に加えて、異なるテナンシとのピアリングを許可するIAMポリシーの設定を忘れると、接続リクエストが失敗します

それでは最後に§6で、ここまで扱ってきたDRGルートテーブル・FastConnect・VCNピアリングの経路設計を1つの構成として統合し、冗長化の設計まで見ていきます。

6. 経路設計の統合と冗長化設計・まとめ

本章では、§2〜§5で個別に扱ってきたFlexible LB/NLB・DRGルートテーブル・FastConnect・VCNピアリングを1つの経路設計として統合し、冗長化の設計パターンまで見ていきます。最後に、本記事全体を振り返ります。

6-1. 経路設計の統合 — 1つのDRGルートテーブルに集約される経路

§3〜§5で個別に扱ってきたVCNアタッチメント・IPSecトンネルアタッチメント・Virtual Circuitアタッチメント(FastConnect)・RPCアタッチメント(リモートピアリング)は、いずれも同じDRGルートテーブルの仕組みの上で、インポート/エクスポートルート配信によって経路制御されます(§3-3)。

この一貫した仕組みが、DRGの設計上の強みです。オンプレミス接続(FastConnect・IPSec)、複数VCNの集約(VCNアタッチメント)、リモートピアリング(RPC)という異なる種類の接続を、個別の仕組みで管理するのではなく、1つのDRGルートテーブルの優先度設計として統合的に扱えます。設計時は、次の順序で経路の全体像を整理すると見通しが良くなります。

1. DRGに接続する予定のアタッチメントをすべて洗い出す(VCN・IPSecトンネル・Virtual Circuit・RPCの種類ごと)
2. 各アタッチメントに割り当てるDRGルートテーブルを決め、共有するか個別に持たせるかを設計する
3. インポートルート配信で、どのアタッチメントからの経路をどのルートテーブルに学習させるかを、マッチ条件と優先度で明示する
4. エクスポートルート配信で、どのアタッチメントへどの経路を配信するかを設計し、意図しない通信経路(§3-4のスポーク間通信など)を排除する

6-2. ECMPによる冗長化の実践 — FastConnect回線の冗長化

§3-5で仕様を整理したECMPは、FastConnectの本番運用で特に重要になります。単一のFastConnect回線・単一拠点に依存した構成では、その回線または拠点の障害がそのままオンプレミス接続の断絶につながるためです。

6-3. ハブアンドスポーク構成の冗長化パターン

§3-4で扱ったハブアンドスポーク構成において、ハブVCNにネットワーク仮想アプライアンス(ファイアウォール等)を配置する場合、そのアプライアンス自体の可用性設計も必要です。ここで、§2-7で扱ったフォルトドメインによる冗長化の考え方がそのまま活きます。

具体的には、ハブVCN内に異なるフォルトドメインへ分散配置した複数のネットワーク仮想アプライアンスインスタンスを用意し、その前段にプライベートのFlexible LB(§2-4で扱ったAlways Free枠の構築実践と同じ仕組みの、内部向け構成)を配置して、アプライアンスの冗長化と負荷分散を行う設計パターンが考えられます。これにより、LB(§2)・DRGルートテーブル(§3)・FastConnect(§4)・ピアリング(§5)という、本記事で扱ってきた要素がすべて1つの本番構成の中で組み合わさります。

6-4. AWS Transit Gatewayのルートテーブル設計との対比

DRGルートテーブルとAWS Transit Gateway(TGW)のルートテーブルは、複数のVPC/VCNを集約するハブとして機能する点で役割が近い一方、経路制御の仕組みには違いがあります。

大きな違いとして、AWSのTGWは経路の伝播をデフォルトで有効にしたうえで、意図しない中継を防ぎたい場合はブラックホールルートを明示的に追加する設計が基本です。一方OCIのDRGは、§3-4で確認した通り、IPSecトンネル・Virtual Circuitアタッチメント同士の中継はデフォルトで無効という、より安全側に倒れた挙動がデフォルトになっています。この違いを理解しないまま「TGWと同じ感覚で、明示的に遮断しない限り中継されるはず」という前提で設計すると、意図した経路が学習されず、疎通試験の段階でつまずくため注意してください。

6-5. まとめ

本記事では、「OCIネットワーク実践(Production編)」シリーズの第1弾として、§2でFlexible Load Balancer/Network Load BalancerをAWSのALB/NLBと対比しながらAlways Free枠で構築し、§3でDRGのルートテーブル・アタッチメント・ECMP・ハブアンドスポーク構成を実装レベルで扱いました。§4ではFastConnectの接続方式と拠点選定、§5ではDRG経由を主軸としたVCNピアリングの実装を解説し、§6では、これらすべてを1つのDRGルートテーブル設計として統合し、ECMPやフォルトドメイン分散による冗長化パターンまで確認しました。

本記事は、「OCI入門」シリーズVol3がVCN・サブネット・ゲートウェイの基礎を扱ったのに対し、その先にある本番運用レベルのネットワーク設計を一気通貫に扱いました。Vol3で基礎を確認してから本記事に進むことで、DRGやFastConnectといった個々のサービスの役割だけでなく、それらを組み合わせた1つの経路設計として本番構成を組み立てる考え方が身につくはずです。AWSでのネットワーク設計経験を土台に、まずはAlways Free枠でFlexible LB/NLBの操作感を掴み、DRGルートテーブルの設計を試しながら、本記事で扱った本番運用の勘所を実務に活かしてみてください。

→ OCI入門 Vol3: VCN・サブネット・ゲートウェイ・セキュリティ