はじめに
2026年4月1日に、Oracle Database@AWS（以下Oracle@AWS）向けの新機能「ハイパフォーマンスネットワーキング（High Performance Networking）」が発表されました。
2025年7月のOracle@AWSのGAからまだ1年弱ですが、エンタープライズの基幹系システム移行を後押しする機能が早くも追加されたな、という印象を受けました。
記事で述べられていますが、決済処理や高頻度トランザクション（OLTP）など、ミリ秒単位の遅延が重要となる要件では、クラウド移行時に「ネットワークレイテンシのばらつき」が大きな壁になることがあります。今回のアップデートは、その課題をAWSのネイティブな機能（プレイスメントグループ）との連携で解決するアプローチになっています。
新機能がリリースされたということで、いったん私自身も情報を整理しておこう、という意味も含めてこちらでご紹介します。今回はどちらかというと、オンプレミスのExadata環境からクラウドへの移行を検討しているDBAの方や、パフォーマンス要件の厳しいデータベースをAWS上で設計・運用するクラウドエンジニアの方々に参照してもらえるような内容にしたいと考えています。
従来のOracle DB環境におけるネットワークの課題
オンプレミスでOracle Exadataを運用している環境では、アプリケーションサーバーとデータベースサーバーが同じデータセンター内の非常に近い物理ラックに配置され、専用の高速ネットワークで接続されていることが一般的でした。これにより、極めて低く、かつ「ばらつきのない」レイテンシ（遅延）が保証されていました。
一方で、これらをOracle@AWSへ移行する場合、これまではネットワークレイテンシの担保がひとつのハードルとなっていました。
OCI側のネットワークトポロジドキュメントにもある通り、Oracle@AWSではアプリケーションが稼働するVPCと、データベースが稼働するODBネットワークを同じアベイラビリティゾーン（AZ）に配置することである程度のネットワークパフォーマンスを確保していました(Oracle@AWSのSLAは2ミリ秒未満1)。
しかし、広大なAWSのAZ内において、EC2インスタンスとExadataインフラストラクチャが「物理的にどれくらい離れた場所に配置されるか」まではコントロールできませんでした。そのため、ネットワークのホップ数や物理的な距離によってレイテンシに微小なばらつき（ジッター）が生じる可能性があり、ミリ秒未満のシビアなレスポンスが要求される基幹システムにおいては、影響が出る場合がありました。
新機能「ハイパフォーマンスネットワーキング」とは？
今回発表された「ハイパフォーマンスネットワーキング（High Performance Networking）」は、この物理的な距離の課題を AWSネイティブな仕組みである「Amazon EC2プレイスメントグループ」 を活用して解決するものです。
仕組みは非常にシンプルかつ強力です。
Oracle@AWSで新しく「ODBネットワーク」を作成すると、裏側でAWSによって自動的に専用のプレイスメントグループ2がプロビジョニングされ、ODBネットワークに関連付けられます。
利用者は、アプリケーション用のEC2インスタンスを起動する際に、この自動生成されたプレイスメントグループを指定するだけです。これにより、EC2インスタンスはAZ内において Oracle Exadataインフラストラクチャに物理的に最も近い場所（近接配置）に起動される ことが保証されます。ネットワークホップが最小化されるため、レイテンシのばらつきが抑えられ、一貫したパフォーマンスを発揮できるようになります。
従来環境からの3つの改善ポイント
この機能により、具体的に以下の3つのメリット・改善点が得られます。
① 一貫したサブミリ秒の低レイテンシの保証
最大のメリットはこれに尽きます。EC2からOracle Database@AWSへのラウンドトリップにおいて、一貫して「サブミリ秒（1ミリ秒未満）」のレイテンシが提供されます。オンプレミスのExadata環境向けに極限までチューニングされたアプリケーションであっても、同等のネットワークパフォーマンスをAWS上で再現しやすくなります。
② 既存のEC2ワークフロー・コストモデルとのシームレスな統合
この近接配置を実現するために、特殊なAPIや専用のコンピュートリソースを用意する必要はありません。
また、Amazon EC2 On-Demand Capacity Reservations（ODCR）やSavings Plans、リザーブドインスタンスとも互換性があるため、これまでのAWS運用ノウハウやコスト最適化の手法をそのまま適用できるのは、運用者にとって非常にありがたいポイントです。
③ 追加コストなし
ハイパフォーマンスネットワーキングの機能自体に、追加の利用料金はかかりません。起動したEC2インスタンスの通常の利用料金のみで、この物理的な近接配置の恩恵を受けることができます。
対象となる主なユースケース
今回のアップデートは、以下のような「レイテンシへの要件が極めて厳しいミッションクリティカルなシステム」のクラウド移行に直結します。
- 決済処理システム: 1トランザクションの遅延がビジネスインパクトに直結するシステム
- 証券取引プラットフォーム: マイクロ秒〜ミリ秒単位のレスポンスが要求される金融システム
- 高頻度トランザクション処理（OLTP）: 膨大な同時接続と細かいクエリが連続して発生する基幹システム
- 製造実行システム（MES）: 工場などのIoTデバイスとリアルタイムに連携し、瞬時のデータ処理が求められる環境
逆に言えば、バッチ処理メインのシステムや、数ミリ秒の遅延が許容される一般的なWebアプリケーションであれば、従来の標準的なVPCピアリング構成でも十分なケースが多いと考えられます。要件に応じた使い分けが重要です。
まとめ
2026年4月に発表されたOracle Database@AWSのハイパフォーマンスネットワーキングについて整理しました。
オンプレミスのExadataと同等のネットワークパフォーマンスを、AWSの使い慣れたプレイスメントグループの仕組みで、しかも追加コストなしで実現できるようになったことは、大きなブレイクスルーだと感じています。これまで「パフォーマンス（遅延）の壁」でAWSへの移行を見送っていたエンタープライズシステムにとっての選択肢となるはずです。
そして、日本のユーザーにとって非常に重要な点として、このハイパフォーマンスネットワーキング機能は、既に東京リージョン（ap-northeast-1）でも利用可能であることが発表されています。これにより、国内の基幹システムも遅延を極小化した環境へスムーズに移行できるようになります。
なお、本機能を検証するにあたっては、公式ドキュメントにネットワークレイテンシの測定方法（Measuring network latency）についてのベストプラクティスも記載されています。pingなどの簡易的な測定だけでなく、実際のデータベース接続（tnspingなど）やTCP レベル遅延測定ツールである(sockperf)を用いた検証のポイントが案内されていますので、導入の際はこちらもあわせて参照されることをお勧めします。
既存環境上でハイパフォーマンスネットワーキングを利用を開始する際の注意点
前述の通り、プレイスメントグループの自動関連付けはODBネットワークの新規作成時に行われる動作です。既存のODBネットワークに対して後からプレイスメントグループを追加する仕組みは現時点では提供されていないため、この機能を利用するにはODBネットワークの再作成が必要になります。
ここで注意すべきは、「ネットワークだけ作り直せばよい」という単純な話ではない点です。
Oracle blog3によると、ODBネットワークを削除するには、事前にODBピアリング接続およびすべてのExadata VMクラスター（配下のCDB・PDBを含む）を削除する必要があります（Exadataインフラストラクチャ（物理基盤）の削除は不要）。
つまり、実際の作業スコープとしては 「ピアリング削除 → VMクラスター削除 → ODBネットワーク削除・再作成 → VMクラスター再構築 → データベースのリストア → ピアリング再設定」 という一連の流れになります。当然、VMクラスターの削除前にはデータベースのフルバックアップが必須です。
また、新しいODBネットワークを作成すると、プレイスメントグループが自動的に生成されます。既存のEC2インスタンスをこのプレイスメントグループに関連付けるには、modify-instance-placementコマンドを使用します。ハイパフォーマンスネットワーキングの恩恵を受けるにはこの関連付けが必須となるため、EC2側の作業も移行計画に含めておく必要があります。
以上を踏まえると、本番環境への適用はかなりの計画的ダウンタイムを伴う作業となることが想定されます。新規にOracle@AWS環境を構築する場合は最初からこの機能の恩恵を受けられますが、既存環境の場合はメンテナンスウィンドウの確保やリストア手順のリハーサルを含めた移行計画を十分に検討することをお勧めします。