クラウドインテグレーション事業部の片山です。
2026年10月26日〜28日（現地時間）にラスベガスで開催中のイベント、Oracle AI World 2026に今年も現地参加しています。

昨日はパートナー向けのセッションや事前受付のみでしたが、本日（現地26日）は遂に一般開場です！
朝から会場はかなりの人出で、特に午前のKeynoteは満員！終了後、しばらくは人の波に流される形で中々動けないほどでした…！！
今回は「Top 10 Network Architecture Decisions for Modern Cloud Applications」というセッションのレポートをお届けします。

セッション概要

本セッションは、OCI（Oracle Cloud Infrastructure）上に仮想ネットワークを構築する際にアーキテクトが直面する10の設計判断を、「選択肢・構成例・判断軸」の3点セットで順に解説する45分のLearning Sessionです。ざっくり言うとOCIのNW基礎まとめ編の様な形で、本イベントのセッションの中では割と易しめの方かなと思います。これからOCIを触ろうとしている方や活用してみたいけどNW部分の整理がついていない！という方には是非読んでいただきたいです。
登壇者はOracleのLiyuan Quan氏（Lead Principal Core Infrastructure Architect, OCI Networking）で、冒頭にOCI Networkingのプロダクトマネジメント組織を率いるPaul Cainkar氏からチーム紹介がありました。

Quan氏は「クラウドのネットワークは家を建てるようなもの」と切り出し、サブネットからDNSまで構築する順番どおりに、各論点でOracleとしての推奨を示していきました。

セッション内容：OCIネットワーク設計、10の分かれ道とOracleの推奨

土台をつくる：サブネットとVCN間ルーティング（論点1・2）

論点1：パブリックサブネットかプライベートサブネットか。プライベートサブネットは外部起点の通信を受け付けず、必要ならNAT Gateway経由で外向きの通信だけを許可します。判断軸は、外部からのアクセスが必要か、公開を防ぐ境界が要るか、パッチ適用や監視のためにインターネットへ出る必要があるか、の3点です。Quan氏が強調していたのは、同じVCN内であればサブネットの種別に関係なく既定で経路は開いているという点で、分離はルーティングではなくセキュリティポリシーで担保するというOCIの考え方がよく表れていました。

論点2：VCN同士をどうつなぐか。選択肢はLPG（Local Peering Gateway）とDRG（Dynamic Routing Gateway）です。LPGは同一リージョン内の2つのVCNを手早くつなげますが、トランジットができずVCNあたり10個までという上限があるため、「スケールする環境ではDRGを」というのがOracleの明確な推奨でした。DRGは1台あたり最大300のVCNをアタッチでき、アタッチメントごとのルートテーブルでフルメッシュにもハブアンドスポークにも組めます。判断軸は、つなぐVCNの数、ポイントツーポイントかメッシュかという接続パターン、接続先がVCNかリージョン間かオンプレミスか、の3点で、遅延に極めて敏感な少数VCNの接続においてはLPGが有利になる例外も挙げられていました。なお2021年5月より前に作成した旧世代のDRGは、新機能を使うためにアップグレードが必要とのことです、

OCIの外へ出る：オンプレミス接続と専用線上の暗号化（論点3・4）

論点3：インターネット、IPsec VPN、FastConnectのどれでオンプレミスとつなぐか。Quan氏の整理は明快で、PoCはSite-to-Site IPsec VPNでまず素早くつなぎ、本番のハイブリッド構成はFastConnect、というものです。IPsec VPNは即座に構成できる一方でトンネル単位の帯域に上限があり、FastConnectは1・10・100・400 Gbpsのポート速度を持つ専用のプライベート接続で、FastConnectを主系にしつつIPsec VPNをバックアップとして残す構成も推奨されていました。判断軸は、PoCか長期利用か、導入時期・帯域・予算、BYOIPやBYOASNの要否、OracleのIPレピュテーションやASNがクライアントに影響しないか、の4点です。

論点4：FastConnectの上をさらに暗号化するか。金融機関などは専用線上でも暗号化を求めます。選択肢はMACsecとSite-to-Site VPN over FastConnectで、MACsecはレイヤー2の標準規格として対応ルーターがあればほぼラインレートの性能が出るのに対し、IPsec over FastConnectはインターネット経由のIPsecと同じ性能上限に縛られます。判断軸は、自社やパートナーの機器がMACsecに対応しているか、IPsecのオーバーヘッドと帯域上限を許容できるか、そして暗号化が維持できなくなったときに通信を継続する（should-secure）か止める（must-secure）かの3点で、最後の問いを設計時に決めておくべきだという指摘が印象的でした。

クラウドをまたぐ：マルチクラウド接続とOracle Databaseの置き場所（論点5・6）

論点5：マルチクラウド接続をどう実現するか。「GPUクラスターはOCI、アプリケーションやデータは別のクラウド」という構成を例に、3段階の選択肢が示されました。第1はOracleと各クラウドが直接相互接続しているOCI Multicloud Interconnectで、OCI側はFastConnect、相手側はAzure ExpressRouteやGoogle Cloud Interconnect、AWS Direct Connectを注文するだけで接続が成立します。第2は接続パートナーの回線、第3はIPsec VPNです。判断軸は、使いたいリージョンに相互接続が提供されているか、両クラウドのネイティブな操作感と一体化したサポートを重視するか、帯域や遅延がパートナー回線の容量と契約に左右されることを許容できるか、です。

公開情報の補足として、AWSとの相互接続「Oracle Interconnect for AWS」は2026年7月から8月にかけて一般提供が始まったばかりで、現時点ではOCI AshburnとAWS米国東部（バージニア北部）の組み合わせのみです。日本国内ですぐ使えるのはGoogle CloudとAzure、というのが2026年10月時点の実態となります。

論点6：Oracle Databaseをどこに置くか。OCI上にフル機能のOracle Databaseを置くか、アプリケーションが動くクラウド側でOracle Multicloud Database Services（Oracle AI Database@Azure、@Google Cloud、@AWS）を使うかの選択です。後者はアプリケーションとの近接性と、そのクラウドのネイティブな管理・課金・サポートが利点で、判断軸は遅延要件と統一サポートの要否、自分でインスタンスを管理したいかです。

守りと仕上げ：セキュリティ、ファイアウォール、ロードバランサー、DNS（論点7〜10）

論点7：Security List、NSG、ZPRをどう使い分けるか。OCIは明示的に許可しない通信を遮断するホワイトリスト方式です。Security Listはサブネット単位、NSG（Network Security Group）はリソース単位で適用されるため、「共通ルールをSecurity Listに、階層ごとのルールをNSGに重ねる」という組み合わせが勧められました。その上に位置づけられるのがZPR（Zero Trust Packet Routing）で、リソースに付けたセキュリティ属性に対して自然言語に近いポリシー文でアクセスを定義します。判断軸として、リージョン全体で統一された読みやすいポリシーが欲しいか、監査やコンプライアンス報告を簡単にしたいか、セキュリティ設計をネットワーク設計から切り離したいか、同じサブネット内で5セットを超えるルールが必要になるか、が挙げられていました。セッションでは「ZPRでdenyルールが使えるようになった」という説明もありましたが、公開ドキュメントへの反映は本稿執筆時点で確認できていません。ZPRの場合、暗黙のDenyが前提という理解のため、これによってどういった変更が出るか、公式の続報を待ちたいところです。

論点8：ファイアウォールはマネージドかサードパーティか。OCI Network FirewallはPalo Alto Networksの技術を基盤とするマネージド型の次世代ファイアウォールで、冗長性が組み込まれ、インスタンスやソフトウェア更新の管理が不要です。OCI Marketplaceのサードパーティ製を選ぶ判断軸は、サードパーティにしかない機能が必要か、既存のベンダー契約やSOC・NOCとの連携要件があるか、単一のサポート窓口を優先するか個別のサポートモデルを許容するか、です。そのうえで「そもそもファイアウォールが必要か、ZPRやNSGとWAFで足りないか」から考える、という問いが最初に置かれていました。

論点9：Network Load BalancerかFlexible Load Balancerか。前者はレイヤー3／4のパススルー型でTCPセッションを終端せず、数百万のフローを低遅延でさばきます。後者はレイヤー4／7のプロキシ型で、HTTPヘッダーに基づく振り分けやTLSオフロード、OCI WAFポリシーの適用ポイントを担います。判断軸は、求める性能レベル、クライアントIPの保持とセッション維持の要否、TLS終端の要否、数百万フローや低遅延の要件があるか、です。

論点10：DNSはクラウドネイティブかハイブリッドか。OCI Cloud DNSはDNSサーバー用のVMが不要で、プライベートDNSのゾーンとビューを使ってオンプレミス側とOCI側でドメインをフォワードし合う構成が示されました。ハイブリッド構成はOCI上に自前のDNSサーバーを立てる方式です。判断軸は、オンプレミス側のシステムの名前解決が必要か、OCIのプライベートDNSビューを活用できるか、サーバーを自分で管理したいかシンプルさを優先するか、の3点です。

おわりに

以上、「Top 10 Network Architecture Decisions for Modern Cloud Applications」に現地参加してのセッションレポートをお届けしました。

本セッションに新しい発表はありませんでしたが、10論点を同じ型で並べたことで、OCIのネットワーク設計の全体像が45分で頭に入る構成でした。VCN内は既定で疎通し、分離はポリシーで行う。VCN間はDRG、本番のオンプレミス接続はFastConnect、専用線上の暗号化はMACsec。Security ListとNSGを重ね、その上にZPRを置く。こうしたOracleとしての推奨が明快に示された点が、本セッションの最大の価値だったと感じています。

弊社はクラウド活用についてお客様をご支援する中で、OCIを含むマルチクラウド環境の実装やそれに伴うクラウド間の接続、Oracle Databaseの配置についてご相談をいただく機会が増えています。他クラウドの経験があればOCIの設計判断は難しくありませんが、Oracle Interconnect for AWSの対応リージョンがまだ米国東部に限られることなど、最新の提供状況を踏まえた設計が必要です。「どこまでが既定で通り、どこからをポリシーで守るか」をお客様と整理することが、我々SIの価値になると改めて感じました。

最後までお読みいただきありがとうございました！